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

With no annotations at all, the description carries the full burden and discloses almost nothing: not what credentials are required, whether the result is a session/token that persists, whether the call is idempotent or safe to repeat, or what happens on failure. The output schema covers return shape, but the behavioral traits of an auth operation remain undocumented.

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

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

A single, front-loaded sentence with no filler or redundancy. Every word earns its place, even if more content is needed.

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

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

The tool is simple (no params) and has an output schema, so the description does not need to explain returns. But for an auth entry point in a large suite with a sibling nws_authenticate, at minimum the prerequisites and the distinction from that sibling should be stated; those gaps keep it at minimum-viable.

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 no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misrepresents or omits parameter behavior.

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 (authenticate) and a specific resource (the NWP app bridge against the configured NWP app server), which is enough to distinguish it from the generic nws_authenticate by scope. However, it never explicitly contrasts itself with the near-identical sibling nws_authenticate, leaving that differentiation implicit.

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 call this versus nws_authenticate or nws_app_status, all of which are plausible siblings an agent would hesitate between. There is no statement of prerequisites, ordering (e.g., must app auth precede nws_app_commit_import?), or what a failure means.

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful behavioral trait — the cancellation makes no remote changes — which is precisely the kind of context structured fields do not provide. However, it omits what happens to the pending confirmation record, whether auth is required, idempotency, and error behavior for an already-committed or expired confirmation.

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 tight sentence with the resource and the scope front-loaded and the side-effect qualifier trailing. Nothing is padded and every clause carries information.

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

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

An output schema exists, so return values need not be described, and the tool is a simple single-parameter mutation. The description covers action, scope, and the absence of remote side effects. What remains thin is lifecycle detail (state of the confirmation after cancel, failure modes) against a tool with no annotation 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?

The single parameter has 0% schema description coverage, so the description must compensate. It partially does: 'one pending NWP import confirmation' tells the agent the confirmation_id must reference a still-pending confirmation, not a completed one. It adds no format, source, or retrieval guidance (e.g., where to obtain the ID).

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 ('Cancel'), a specific resource ('one pending NWP import confirmation'), and a scope ('one'). This is clearly distinct in intent from nws_app_commit_import and nws_app_preview_import, though it never names those siblings to confirm the routing.

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

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

The word 'pending' implies the precondition that a confirmation must not yet be committed, and 'without remote changes' contrasts implicitly with commit. But there is no explicit 'use this when…' or 'do not use if the import was already committed' guidance, and no sibling is named.

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

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

With no annotations, the description carries the full burden, and it does add one genuinely useful behavioral fact: the cancellation happens 'without remote changes', i.e. it is a local discard with no remote side effects. It says nothing about idempotency, what happens to an invalid/expired confirmation_id, or whether the confirmation becomes unusable, which is a real gap for a state-changing tool with zero annotation coverage.

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 tight sentence with the action front-loaded and zero filler. Nothing could be removed without losing meaning.

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

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

An output schema exists, so return values need no explanation, and there is only one required parameter. What is missing is the origin of the confirmation_id and the behavior on invalid input; otherwise the definition is sufficient to call the tool.

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

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

Schema coverage is 0%, so the single required parameter 'confirmation_id' is undocumented in the schema. The description only implies that the id refers to a pending publish confirmation; it does not say how the id is obtained or what format it takes. That is partial compensation for a low-coverage 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 ('Cancel') and a specific resource ('one pending NWP publish confirmation'), which sets it apart from the preview/commit publish siblings. It stops short of naming those siblings as the alternative path, so differentiation is inferred rather than stated.

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

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

The word 'pending' implies this only applies to a confirmation that has been previewed but not committed, which is useful implied guidance. There is no explicit when-to-use, no statement of what to do if the confirmation is already committed or expired, and no named alternative (e.g. nws_app_commit_publish).

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

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

With no annotations, the description carries the full behavioral burden and does disclose the most important trait: submissions are removed from the app queue, i.e. the operation is consequential. It says nothing about required permissions, whether the import is atomic, what happens to the queue entries if it partially fails, or how long the confirmation_id stays valid.

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

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

A single front-loaded sentence with no filler; the verb and the side effect arrive immediately. It is efficient, though the brevity borders on under-specification given the missing prerequisite context.

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

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

An output schema covers return values, but for a commit-style mutation with zero annotation coverage the description should at minimum establish the preview prerequisite and the provenance of confirmation_id. Neither is present, leaving the agent to infer the workflow entirely from sibling names.

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

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

Schema coverage is 0% and the single parameter (confirmation_id) is never mentioned in the description. The origin of that ID — presumably returned by nws_app_preview_import — and its lifetime are exactly what an agent needs and exactly what is missing, so the description does not compensate for the coverage gap.

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

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

States a specific verb (import), a specific resource (previewed NWP app submissions), and adds the consequential side effect of removing them from the app queue. The preview/commit/cancel triplet among siblings makes the role clear without needing to open a schema, though the description does not explicitly name nws_app_preview_import as its partner.

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

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

Usage is only implied by the preview/commit/cancel naming convention — an agent can infer this is the terminal step after a preview. There is no explicit statement that a preview must precede this call, no exclusion of the cancel path, and no guidance on when NOT to commit.

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?

No annotations are provided, so the description carries the full behavioral burden, and it says nothing about permanence, permission requirements, or whether confirmation_id expires. The only behavioral hint is that notifications are sent-or-skipped explicitly, which is really parameter information rather than disclosure of side effects.

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

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

A single front-loaded sentence with no filler that names the action, the object, and the notification decision. It is efficient rather than under-specified, though one more clause about the confirmation_id would have earned the 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?

An output schema exists, so return values need not be described. But for a no-annotation mutation tool with 0% schema coverage on two required parameters, the description leaves the agent without the confirmation_id lifecycle and without any notion of irreversibility — significant gaps for a publish 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 0%, so the description must compensate. It glosses send_notifications ('explicitly send or skip notifications') but never explains confirmation_id — where it comes from, that it is issued by the preview call, or whether it is single-use/expiring. A caller cannot infer how to obtain the required value.

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

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

States a specific verb ('Publish') and resource ('NWP release') and qualifies it with 'previewed', which signals it is the commit step of a preview/commit pair. It is distinguishable from nws_app_preview_publish and nws_app_cancel_publish, though it never names those siblings 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?

'previewed' implies a prior preview step is a prerequisite, giving implied usage guidance. However, there is no explicit statement about when to use this versus cancel or re-preview, and no mention of what happens if the preview is stale.

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?

No annotations are supplied, so the description carries the full burden. 'Preview' hints that nothing is written, but the description never states that no data is modified, whether a token or handle is returned for a later commit, whether authentication is needed, or how pending submissions are scoped.

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 compact sentence with no filler, and the key noun phrase is front-loaded. Its brevity is a virtue, but it comes at the price of detail rather than because of efficient coverage.

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

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

An output schema exists, so return values need no explanation, but the definition still omits what 'preview' produces, what happens to pending submissions, and what the two parameters do. For a two-parameter tool with no annotations, this leaves significant 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 description coverage is 0% and neither parameter (ui_text, data_types) is mentioned. The description does not explain what either one filters or overrides, leaving both effectively undocumented.

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

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

The description uses a specific verb and resource: preview importing pending NWP app submissions into NWS congregation data. It is clearly readable as a dry-run counterpart to nws_app_commit_import, but that distinction comes only from the 'preview' prefix, and no sibling is ever named.

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

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

The description says nothing about when to use this versus nws_app_commit_import or nws_app_cancel_import, nor what condition makes previewing appropriate. The workflow, preview and then commit or cancel, is left entirely to inference from names.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It does state one useful trait—that the tool pauses to ask about notifications—but it says nothing about whether previews have side effects, are persisted, expire, resemble a commit token, or require authentication. That leaves the safety profile largely undisclosed.

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 no padding, and the core action comes first. The only cost is the cryptic 'NWP', but the structure is otherwise efficient.

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 output schema covers return values, and the workflow hint covers ordering. However, for a stateful preview step with zero annotations and an undocumented optional parameter, the description is too thin: it does not cover prerequisites, side effects, or parameter meaning.

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 only parameter, entity_types, has 0% schema description coverage, and the description says nothing about it: it does not explain what entity types are, what omitting the parameter means as a filter, or what values are valid. With coverage this low, the description should compensate, but it does not.

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

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

The description names a specific verb plus resource: previewing a publish operation. Together with the matching sibling names nws_app_commit_publish and nws_app_cancel_publish, this lets an agent infer that it is the first step of a preview/commit/cancel triad. However, the description never explicitly contrasts this tool with those siblings, and the acronym 'NWP' is unexplained.

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 'then ask whether notifications should be sent' implies that this tool is a pre-commit step and that the agent should collect user intent before proceeding. However, the description never names nws_app_commit_publish as the follow-up or says when not to use this tool; the usage guidance is only implied.

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

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

With no annotations, the description carries the full disclosure burden. 'Return ... summary' implies a read with no side effects and 'value-free' hints that no sensitive payload is exposed, which is genuinely useful context, but it never states read-only-ness, permission requirements, or what 'pending imports' means operationally.

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 front-loaded sentence with no filler, which is appropriately sized for a zero-argument status call. The only inefficiency is the unexplained 'value-free' qualifier, which consumes attention without resolving meaning.

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 output schema exists, so return values needn't be described, and with no parameters the input surface is trivial. Still, for a tool whose only job is interpretation of scope, leaving 'NWP app bridge', 'pending imports', and the boundary against nws_status unexplained leaves the agent guessing.

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 no parameter semantics to explain; the baseline for a parameterless tool applies. Nothing in the description misleads about inputs.

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

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

The description names a specific verb ('Return') and a specific subject ('summary of the NWP app bridge and pending imports'), so the resource is identifiable. However, 'value-free' is undefined jargon and 'app bridge' is opaque, and nothing distinguishes this from the closely named sibling nws_status or from nws_app_preview_import/nws_app_commit_import, so an agent cannot confidently route between them.

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

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

There is no when-to-use guidance, no prerequisite or auth note, and no reference to any alternative tool. The presence of nws_status and the app_import preview/commit/cancel siblings makes the absence of disambiguation a real gap.

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

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

With no annotations, the description carries the full burden and only hints that an email may be sent and a verification step may follow. It does not say whether credentials are stored, whether this is idempotent, what state results after a successful call, or whether a subsequent verify call is required (nws_verify exists).

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

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

A single compact sentence with no filler. It is slightly under-specified rather than padded, which is a mild issue, but the structure is front-loaded on the primary action.

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

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

An output schema exists, so return values needn't be described. Still, for an authentication entry point with an optional emailed verification branch, the description leaves the agent unsure whether one call suffices or whether nws_verify must follow, and how it relates to nws_app_authenticate.

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 no parameter surface for the description to explain. Baseline 4 applies; the description adds nothing needed here.

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

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

The verb 'Authenticate' and the resource 'NWS' are stated, and a second behavior (email device-verification flow) is named. However, the tool performs two distinct actions under one name with no signal of which occurs when, and there is no differentiation from the sibling nws_app_authenticate.

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 explanation of what triggers the emailed verification path versus direct authentication, and no reference to the obvious sibling nws_app_authenticate as an alternative. The agent must guess which tool to pick.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the output format and that the resulting file is read-only, but says nothing about whether existing files are overwritten, what 'sync_first' triggers, or what permissions/authentication the write requires.

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, front-loaded sentence with no filler, but the compressed phrasing ('write a read-only ... backup') is slightly ambiguous about whether the tool or the artifact is read-only, and brevity here comes at the cost of needed 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?

An output schema exists, so return values need not be explained, but for a two-parameter file-writing tool with no annotations and 0% schema coverage, the description omits critical information about the sync side effect and overwrite semantics.

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

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

Schema description coverage is 0%, so the description must explain both parameters and does not. 'Write ... backup' loosely implies output_path, but the default-true sync_first behavior — a meaningful side effect — is completely undocumented in both schema and description.

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 artifact: write a vendor-compatible .NWSchedulerBackup of the shared data. An agent can tell this creates a backup file, distinct from restore or export siblings, though it does not explicitly contrast with nws_backup_inspect or nws_export.

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

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

No guidance on when to use this versus nws_export, nws_backup_inspect, or nws_sync, and no prerequisites or exclusions. The agent must infer the backup workflow entirely 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?

With no annotations, the description carries the full burden, but it does convey a genuine behavioral trait: results are returned 'by count only', so the agent knows contents are summarized rather than enumerated. It does not state that the operation is read-only/non-destructive, whether the path must exist, or permission requirements — meaningful gaps for an unannotated 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?

A single front-loaded sentence with no wasted words. It is efficiently sized, though arguably too terse given the absent parameter and behavioral 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?

An output schema exists, so return values need not be explained, and the tool is a simple one-parameter read. Still, with no annotations, no parameter documentation, and no usage context, the description is only minimally 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, backup_path, with 0% schema description coverage, so both the schema and description leave its meaning undefined. The description never explains what backup_path points to, the expected format, or how to obtain a valid value, failing to compensate for the coverage gap.

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

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

The description uses a specific verb (Describe) and resource (a vendor backup's contents and restorable categories), making the operation distinguishable from mutation siblings like nws_backup_create or nws_restore_commit. The 'by count only' qualifier clarifies scope. It stops short of explicitly naming which sibling it complements, so a 4 rather than 5.

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

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

Usage is only implied: an agent can infer this inspects a backup, presumably before nws_restore_preview. There is no explicit 'use this when...' statement, no mention of prerequisites, and no comparison to sibling tools such as nws_backup_create or nws_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?

With no annotations provided, the description carries the full burden. It does disclose the important behavior that cancellation results in no remote changes, but it omits permissions, idempotency, and what happens if the confirmation ID is stale or invalid.

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 compact sentence front-loads the action and resource with no wasted words. It is appropriately sized for a simple one-parameter cancellation 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?

The output schema exists, so return values need not be explained. Still, for a tool requiring confirmation_id, the description should briefly connect that ID to the preview step and clarify whether cancellation requires a specific state.

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 only parameter, confirmation_id, has 0% schema description coverage, and the description never mentions it. An agent must infer that it comes from a prior preview/upload/removal step, but that relationship is not stated.

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

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

The description clearly states a specific verb and resource: cancel a pending attachment upload or removal. The phrase 'without remote changes' distinguishes it from commit-style sibling tools, though it does not explicitly name those 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?

The word 'pending' implies this is used after a preview and before a commit, and 'without remote changes' implies it abandons the change safely. However, it does not explicitly say when to use this versus nws_commit_attachment_upload, nws_commit_attachment_removal, or other cancel tools.

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

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

With no annotations, the description carries the full burden, and it does disclose one important trait: no remote data is written. However, it is silent on what happens to the confirmation_id (invalidated? reusable?), how it behaves if the preview was already committed or expired, and whether any local state is discarded.

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

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

One sentence, verb-first, with the key safety property front-loaded and zero filler. Nothing is redundant or buried.

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

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

An output schema exists so return values needn't be described, but for a cancel operation with a required, undocumented identifier and no annotations, the definition is thinner than ideal. The most important missing piece — the origin and lifecycle of confirmation_id — 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 0% for the single required parameter, so the description must compensate and does not — confirmation_id is never mentioned. An agent gets no hint that this ID comes from a prior preview call or what an invalid/expired ID produces.

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 (Cancel) and resource (a pending NWS change preview), and the phrase 'without writing remote data' clarifies the operation's nature. It is reasonably distinguishable from nws_commit_change and nws_preview_change, though it doesn't explicitly differentiate itself from similarly-named siblings like nws_public_speaker_cancel_change or nws_restore_cancel.

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

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

Usage is only implied: an agent can infer this is called to abandon a preview rather than commit it, but the description never states when to use it versus nws_commit_change or how a preview comes into existence (presumably via nws_preview_change). No exclusions or prerequisites 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?

With no annotations, the description does disclose the most important trait: no remote changes are made, so this is a safe local cleanup. It omits other behavior an agent may need – whether the call is idempotent, what happens with an invalid or expired confirmation_id, and how the confirmation_id lifecycle works.

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 tight sentence with zero filler; the key scope constraint ('pending ... preview', 'without remote changes') is 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?

An output schema exists, so return values need not be explained. However, with no annotations and an undocumented parameter, the description should have stated where confirmation_id comes from and whether the preview is discarded permanently; that prerequisite context is missing.

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

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

The sole parameter, confirmation_id, has 0% schema description coverage and is never mentioned in the description. The description does not explain that the ID must come from the preview tool or what form it takes, leaving the parameter's semantics to inference from the name alone.

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

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

States a precise verb+resource: cancel a pending duty auto-assignment preview. The phrase 'without remote changes' distinguishes it from the commit sibling (nws_commit_duty_auto_assign) and makes clear it is the discard step of the preview/commit/cancel triplet.

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?

Implied usage only: an agent can infer it is used to discard a preview created by nws_preview_duty_auto_assign. It does not explicitly name the preview/commit alternatives or state preconditions, so guidance is implicit rather than explicit.

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

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

With no annotations provided, the description carries the full disclosure burden, yet it only implies a read-only introspection call without stating that explicitly. It doesn't mention auth requirements, whether results are static or environment-dependent, or how the coverage report should be interpreted, though the presence of an output schema covers return structure.

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

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

A single front-loaded sentence with no filler. It is efficient, though the terseness leaves several open questions that a slightly longer description could resolve at low cost.

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 tool with a full output schema, the description is minimally adequate: the schema handles the return shape. However, it never situates the tool relative to the many other status/entity meta-tools in the sibling list, leaving a real selection ambiguity unresolved.

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; baseline 4 applies. The description correctly implies a no-argument call by framing the tool as a global coverage report.

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 verb 'Describe' and object 'implemented MCP coverage across NWS Desktop subsystems' give a rough sense of a meta/introspection tool, but 'coverage' is abstract and the description never clarifies whether this returns a list of subsystems, supported operations, or feature flags. It also fails to differentiate from sibling meta tools like nws_status, nws_app_status, and nws_entity_types.

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 indication of when an agent should call this versus nws_status or nws_entity_types, and no prerequisites or exclusions are stated. The agent has to infer the use case entirely 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?

No annotations are provided, so the description carries the full burden. It adds one important behavioral safeguard, the remote-data-unchanged precondition, but does not disclose irreversibility, failure behavior, permissions, or what happens if the precondition fails.

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 front-loaded sentence with no wasted words. The action and the key safety condition are both immediately visible.

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

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

An output schema exists, so return values need not be explained, but for a one-parameter destructive operation with no annotations, the description is too thin. It does not explain where confirmation_id comes from or what the caller should expect if the remote data has changed.

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

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

Schema description coverage is 0% and the single parameter confirmation_id is not described. The word 'previewed' weakly implies the ID comes from a preview operation, but the description does not explain the parameter's role or source.

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

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

The description states a specific verb and resource: remove a previewed attachment. The qualifier 'previewed' and the condition 'if remote data is unchanged' help distinguish it from the preview and cancel siblings, though it does not explicitly name those 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?

It gives one clear usage condition: only remove when remote data is unchanged. However, it does not explicitly say to use this after a preview, nor does it contrast with cancel_attachment_change or preview_attachment_removal, leaving the agent to infer the workflow.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a mutation and an optimistic-concurrency condition ('if remote data is unchanged'), but omits permission requirements, what happens on conflict, reversibility, and how the upload is recorded.

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

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

A single front-loaded sentence with no wasted words. The action and the conditional guard are both stated efficiently.

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

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

An output schema exists, so return values need not be described. But for a mutation tool with no annotations and an undocumented required confirmation_id, the description is only minimally complete: it states the action and staleness condition but not conflict handling or parameter provenance.

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

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

Schema description coverage is 0% and the only required parameter, confirmation_id, is never explained. The word 'previewed' hints that confirmation_id may come from a preview, but the description does not state how to obtain or use it.

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

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

The description states a specific verb and resource: upload a previewed attachment and record it conditionally. This distinguishes it from preview/cancel siblings through the 'previewed' and 'record it if remote data is unchanged' wording, though it does not explicitly name an alternative tool.

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 'previewed attachment' implies the preview step must happen first, and 'if remote data is unchanged' gives a condition for use. However, it does not explicitly name the prerequisite tool, state when not to use it, or point to the cancel alternative.

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

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

With no annotations, the description carries the full burden and does disclose one real behavioral trait: an optimistic-concurrency guard ('if remote data is unchanged'). It stops short of saying what happens when data has changed (error vs. abort), whether the commit is irreversible, or what permissions are needed for this mutation.

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 tight sentence with the action, scope, and precondition all front-loaded. Nothing is wasted and nothing important is buried.

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

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

The output schema means return values need no explanation, keeping the bar lower. Still, for an unannotated mutation tool with an undocumented required parameter, the description should say more about failure behavior and irreversibility before it is complete enough to call safely.

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 single parameter confirmation_id has 0% schema description coverage, and the description never names or explains it. An agent can infer that the identifier comes from the prior preview step, but the description adds no explicit syntax, sourcing, or format guidance to compensate for the empty schema.

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

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

States a specific verb (commit) and resource (one previously previewed NWS change) with an explicit scope qualifier ('one', 'previously previewed'). It implicitly separates itself from the preview/cancel siblings, though it never names them.

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

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

The phrase 'previously previewed' implies this is the second step after nws_preview_change, and 'if remote data is unchanged' gives a precondition. However, it never explicitly states when to use nws_cancel_change instead or what to do when the precondition fails, leaving usage partly inferred.

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

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

With no annotations, the description carries the full burden, and it does disclose one important trait: the commit is conditional on the underlying data being unchanged, i.e. a stale/optimistic-concurrency guard. It says nothing about permissions, whether the write is reversible, or what happens if data changed (error type), which matters 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?

One sentence, front-loaded with the action and resource, with the condition appended immediately. Nothing is wasted and nothing is buried.

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

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

An output schema exists, so return values need not be explained, but for a mutation tool with zero annotation coverage the description should cover the confirmation_id contract and the failure mode when data has changed. It gives only the conditional guard, leaving an agent to guess the rest.

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

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

Schema description coverage is 0% and the single parameter, confirmation_id, is undocumented in both schema and description. The word 'previewed' vaguely hints the id originates from a prior preview call, but its format, lifetime, and how to obtain it are never stated, so the description only marginally compensates.

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 ('Write', i.e. commit) and resource ('previewed duty auto-assignment') plus a condition. The preview/commit/cancel naming convention makes its role distinguishable from nws_preview_duty_auto_assign and nws_cancel_duty_auto_assign, though it never names those siblings 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?

The phrase 'if its input data is unchanged' gives one real precondition for invoking it, and 'previewed' implies it must follow a preview step. But there is no explicit statement of when not to use it or which sibling to pick instead (preview vs cancel), leaving routing to inference from the tool name.

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

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

With no annotations, the description must carry the behavioral load. It signals a read-style introspection and adds a genuinely useful nuance that value types are 'observed' (inferred from actual data, not declared schema), but it never states that the call is side-effect free, what happens for an unknown entity_type, or whether results are cached/sampled.

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

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

A single sentence with zero filler, front-loading the verb and the returned content. Nothing repeats the name or title, and nothing could be trimmed without losing information.

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

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

The output schema covers return values and the description explains what kind of data comes back, which is most of the burden for a one-parameter introspection tool. The remaining gap is the origin/format of the entity_type argument, which is left to the caller to guess.

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

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

Schema coverage is 0% and there are no enums, so the single parameter 'entity_type' is entirely undocumented in structured data. The description merely echoes the phrase 'entity type' without saying whether it expects a machine name, a display label, or a value obtained from nws_entity_types — the one thing an agent needs to call this correctly.

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 (describe) and resource (entity type), plus the payload it returns: friendly field names and observed value types. That clearly separates it from data-fetching siblings like nws_get, though it never explicitly distinguishes itself from nws_entity_types, which likely enumerates the same entity types.

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 introspection framing implies this is a schema/metadata lookup to run before building a query, but the description states no when-to-use condition, no prerequisite (does the entity_type need to exist?), and names no alternative. Usage is inferable rather than instructed.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the file is 'owner-only,' which is useful, but it does not explain authentication, overwrite behavior for output_path, what sync_first does, error handling, or whether the download touches the remote system.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise, though its brevity contributes to the under-specification seen in other dimensions.

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

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

An output schema exists, so return-value detail is not required. However, for a four-parameter tool with no annotations and 0% schema coverage, the description is far too sparse to guide correct invocation or explain sync_first and attachment selection.

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

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

Schema description coverage is 0%, so the description must compensate for all four undocumented parameters. It loosely maps 'entity's attachment' to entity_type/identity and 'local file' to output_path, but does not explain sync_first, attachment selection, path format, or identity expectations.

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

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

The description gives a specific verb and resource: 'Download one entity's attachment' and adds that the result goes to an 'owner-only local file.' That distinguishes it from listing or uploading attachments, but it does not explicitly contrast with sibling tools like nws_list_attachments or nws_preview_attachment_upload.

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

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

It implies the tool is used to download an attachment, but provides no explicit when-to-use guidance, no prerequisites, and no alternatives. The presence of nws_list_attachments and attachment upload/removal siblings makes the lack of routing guidance a real gap.

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?

No annotations are provided, so the description carries the burden. It does disclose a meaningful behavioral trait — counts are from a local cache, implying they may be stale — and the 'List' phrasing implies a safe read. It says nothing about ordering, size, or freshness guarantees beyond that.

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

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

A single front-loaded sentence with no filler. Appropriately sized for a zero-argument catalog tool, though it could add one clause of routing guidance at little cost.

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

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

An output schema exists, so return values need not be explained. However, for a discovery tool in a large sibling set, the missing 'use this before X' guidance leaves a real gap in completeness.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing to document, and the description does not confuse the issue with phantom inputs.

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

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

States a specific verb ("List") and resource ("supported NWS entity types") plus an extra detail (locally cached counts). It is distinguishable in practice from siblings like nws_list and nws_describe_entity, but the description never explicitly contrasts itself with them.

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

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

No guidance on when to call this versus the many sibling listing/discovery tools (nws_list, nws_capabilities, nws_describe_entity). The agent must infer that this is a discovery/catalog step from the wording 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that entities are redacted and the file is owner-only, but it does not explain whether existing files are overwritten, what sync_first does, or what permissions are required.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core action and output constraints efficiently.

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?

Although an output schema exists, the description is too thin for a 4-parameter tool with no annotations and no parameter descriptions. It omits meaningful details about sync behavior, entity filtering, and file overwrite semantics that an agent would need before invoking it.

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

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

Schema description coverage is 0%, so the description must compensate. It only clarifies output_format (JSON or CSV) and implies output_path is a file; it says nothing about entity_types or the default behavior of sync_first.

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 (export), resource (redacted NWS entities), and output form (owner-only JSON or CSV file). It is clear what the tool does, though it does not explicitly differentiate itself from nearby tools like nws_backup_create or nws_list.

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

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

The description gives no guidance on when to use this tool versus alternatives such as nws_backup_create, nws_list, or nws_get. It also does not mention prerequisites like authentication or when syncing should be done first.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the entity is 'redacted' and 'cached', but it does not explain access requirements, staleness implications, or what redaction means in practice.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action and lookup mechanism immediately.

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

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

Although an output schema exists, the input side is underspecified: both required parameters lack schema descriptions, and the description does not compensate for entity_type semantics. For a retrieval tool in a dense sibling set, more context is needed.

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

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

Schema description coverage is 0% for two required parameters. The description clarifies that 'identity' may be an ID or UUID, but it does not explain 'entity_type' or the allowed values for either parameter.

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

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

The description states a specific verb and resource: retrieve one NWS entity by ID or UUID. It is clear what the tool does, though it does not differentiate itself from nearby siblings such as nws_describe_entity or nws_list.

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

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

The phrase 'one ... entity' implies single-entity lookup, but there is no explicit guidance on when to use this instead of nws_list or nws_describe_entity. No prerequisites or exclusions 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 are absent, so the description carries the full burden, yet it only discloses that results are 'redacted' and 'cached' – useful, but silent on staleness, ordering, pagination semantics, and any auth requirements for a tool whose siblings include nws_authenticate. No contradiction, but far from adequate disclosure for an unannotated read 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?

One short sentence, front-loaded with the verb and resource, with no filler. It is efficient rather than padded; the terseness is a coverage problem, not a verbosity problem.

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

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

An output schema exists so return values needn't be explained, but the required, enum-less entity_type parameter is undocumented in both schema and description, and there is no guidance on how listing relates to nws_get. For a 4-parameter tool with zero schema coverage, this leaves the agent guessing.

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% across four parameters. The description only gestures at 'query' via 'optional text filtering' and never addresses the required 'entity_type', nor limit/offset. An agent cannot learn valid entity_type values or pagination behavior from either the schema or the description.

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 (List) and a resource (NWS entities), with qualifiers 'redacted' and 'cached' that hint at the data's nature. But it never says what an 'NWS entity' is, and with siblings like nws_get, nws_entity_types and nws_describe_entity in the set, it does nothing to distinguish listing from fetching or describing.

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 statement of when to use this versus nws_get, nws_describe_entity or nws_entity_types, and no prerequisites such as prior authentication. The only usage hint is the phrase 'optional text filtering', which does not route the agent anywhere.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the attachments are 'cached' but does not explain whether the operation is read-only, whether sync_first triggers a sync side effect, authentication requirements, pagination, or what happens when the cache is stale.

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

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

The description is a single front-loaded sentence with no wasted language. It is appropriately concise, though its brevity contributes to missing behavioral and parameter 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?

An output schema exists, so return-value explanation is not required. However, with no annotations and 0% schema description coverage, the description is too thin: it does not cover sync_first behavior, entity_types filtering, or read-only assumptions, which are important for correct invocation.

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

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

Schema description coverage is 0% for both parameters. The description mentions attachment categories that loosely hint at entity_types, but it never explains the sync_first flag, acceptable entity type values, defaults, or how entity_types filters results.

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

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

The description gives a specific verb and resource: it lists cached announcement, document, and territory-map attachments. This clearly separates it from attachment mutation tools and download_attachment, though it does not explicitly name a sibling alternative or distinguish itself from broader list 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?

There is no guidance on when to use this tool versus alternatives such as nws_list, nws_get, nws_entity_types, or nws_download_attachment. The description implies a listing use case but does not state prerequisites, exclusions, or alternative selection criteria.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the underlying action is permanent and that this tool previews it, but it does not clarify that the preview itself is non-mutating, nor does it mention permissions, side effects, or what state is being previewed.

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

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

The description is a single front-loaded sentence with no wasted words. Its brevity is appropriate structurally, even though other dimensions need more 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 two-parameter tool with no annotations and zero schema description coverage, one sentence is not enough. The output schema can cover return values, but the description still leaves the required parameters and preview behavior under-explained.

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

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

Schema description coverage is 0%, so the description must explain the two required parameters. It hints that the target may be an attachment or territory map, which partially maps to entity_type, but it says nothing about the required identity parameter or accepted values.

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

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

The description states a specific verb and resource: preview the permanent removal of an attachment or territory map. It is clear enough to distinguish from commit/cancel removal siblings by the word 'preview,' though it does not explicitly name those 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?

The word 'preview' implies this is a dry-run step before an actual removal, which gives some usage context. However, it does not explicitly say when to use this versus nws_commit_attachment_removal or nws_cancel_attachment_change, nor does it list prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden. It indicates a preview operation and accepted file types, but it does not disclose whether the preview changes state, what permissions or identity context are required, or how the preview relates to a later commit.

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

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

The description is a single front-loaded sentence with no filler. It is efficient, though its brevity leaves little structure for an agent needing more 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?

With three required parameters, no annotations, and no input-schema descriptions, the definition is too thin. An output schema exists, so return values need not be described, but the input semantics and the relationship to the commit/cancel attachment siblings are missing.

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

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

Schema description coverage is 0%, so the description must explain all three required parameters. It only indirectly hints at file_path by listing PDF/JPG/PNG files and a territory map; entity_type and identity remain completely undocumented.

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 and resource: "Preview adding" an attachment or territory map. It also names accepted file types, so an agent can tell what the tool does, though it does not explicitly distinguish this from the commit-attachment sibling.

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

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

There is no guidance on when to use this preview versus nws_commit_attachment_upload, nws_cancel_attachment_change, or nws_preview_attachment_removal. The word "Preview" implies a pre-commit step, but the description does not state that condition or any alternatives.

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

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

With no annotations, the description does real work: it discloses that this is non-mutating and that the confirmation ID expires after 10 minutes. It does not say what happens when a commit arrives after expiry, whether the preview validates the values, or whether it locks the entity against concurrent edits.

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 well-formed sentence with no filler, front-loading the action and closing with the concrete artifact returned. Nothing could be cut without losing 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?

An output schema exists so return values needn't be explained, but with zero annotation coverage, four undocumented parameters, and a required commit/cancel handoff, the definition is too thin for an agent to invoke this correctly in a larger workflow.

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

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

Schema description coverage is 0% across all four parameters, so the description must compensate and largely does not. The words 'create, update, or delete' loosely map to the required operation field and 'values' is hinted at, but entity_type, identity, and the expected shape of values are left entirely undocumented.

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 (preview) plus the set of operations being previewed (create, update, delete) and its distinctive output (a confirmation ID). It is clearly distinguished from a read or list tool, though it never names the natural partners nws_commit_change and nws_cancel_change.

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 10-minute confirmation ID implicitly conveys that this is a two-step flow, but the description never says to call nws_commit_change to apply the change or nws_cancel_change to discard it. For a preview tool whose entire reason to exist is the paired commit/cancel siblings, that omission leaves the workflow 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?

With no annotations, the description carries the full burden; it does disclose the important behavioral trait that this is a non-mutating preview that yields a confirmation ID for a later commit. However, it is silent on whether the preview creates any pending state, how long the confirmation ID stays valid, and whether a running desktop app is required — real gaps for an unannotated 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?

The core action and return value are front-loaded in one sentence, with parameter semantics following in compact clauses. Slightly dense phrasing ('the last two arguments mirror the local desktop settings') costs a bit of clarity but nothing is wasted.

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

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

An output schema exists, so return-format detail is not required, and the description covers the intent, the confirmation-ID handoff, and five of six parameters. The missing 'weeks' semantics and the absence of any desktop-app dependency note are the only meaningful omissions.

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

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

Schema coverage is 0%, so the description must compensate, and it does for most parameters: start_date is explained as a duties schedule row with its Monday/Saturday rule, duty_types gets the valid Duty1P1…Duty9P2 range and default, recent_filter gets its enum values, and the last two args are tied to desktop defaults. Only 'weeks' is left completely unexplained.

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+resource ('Preview the desktop duty auto-assignment') and notes the key output ('return a confirmation ID'), which clearly separates it from siblings nws_commit_duty_auto_assign and nws_cancel_duty_auto_assign. It stops short of naming those siblings explicitly, so it lands just below the top mark.

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 preview-then-confirm-ID framing implies the intended workflow (preview now, commit later with the returned ID), but the description never says to use this before nws_commit_duty_auto_assign or what to do if the preview is rejected. Usage is inferable rather than stated.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It notes that output can optionally go to a file, but it does not disclose permissions, overwrite behavior, side effects of sync_first, or whether the operation mutates data. The missing safety and side-effect context is a significant gap for a tool that may write files.

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

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

The description is front-loaded with a concise purpose sentence, followed by a dense but relevant options list. The option names are useful because the schema has no descriptions, and there is little filler, though the list could be formatted more clearly.

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

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

An output schema exists, so return values need not be explained. However, with no annotations and 0% schema description coverage, the description leaves top-level parameters and operational behavior underdocumented; only partial nested options are covered. It is not complete enough for confident invocation.

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

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

Schema description coverage is 0%, so the description must explain all five parameters. It helpfully names many nested option keys for two report types, but it omits the meaning of report_type values, sync_first, output_path, output_format, and most option value formats. The partial options list adds some value but leaves major parameter semantics undocumented.

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 clear verb and resource: "Build the data of a supported desktop print layout, optionally to a file." It also names the two supported report types (TerritoryAssignmentRecords and TerritoryCards). It does not, however, distinguish this tool from the sibling nws_print_layouts tool.

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 usage by listing options for two report types, but it never states when to use this tool versus nws_print_layouts, nws_export, or other siblings. There are no when-not conditions or alternative-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?

No annotations are provided, so the description carries the full burden, yet it only implies a read operation through the verb 'List'. It does not state that authentication is required, that results are scoped to the current user's access, or whether the listing is paginated.

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 well-formed sentence with the resource and the three reported attributes front-loaded. Nothing is wasted or buried.

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

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

An output schema exists, so return-value explanation is not needed, and the zero-parameter surface is fully covered. However, for a per-user access-scoped listing the description omits auth requirements and usage context, leaving gaps that annotations would otherwise have filled.

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

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

The tool takes zero parameters, so per the baseline this scores 4. There are no argument semantics needing explanation.

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 (desktop print layouts) plus the fields reported (support level, person's access). It is distinguishable from the singular sibling nws_print_layout only by inference from the name, not by explicit contrast in the description.

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 nws_print_layout or any other sibling, and no prerequisites or exclusions are given. The agent must infer the enumeration-vs-detail relationship from tool names 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?

With no annotations at all, the description carries the full disclosure burden. 'Without remote changes' is a genuinely useful trait — it tells the agent this is a local-only rollback with no server-side mutation — but it does not say whether the operation is idempotent, whether the confirmation id becomes invalid afterwards, or what permissions are needed.

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, front-loaded sentence with no filler. It is efficient, though the terseness is partly the reason key details (parameter origin, preconditions) are absent.

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

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

An output schema exists, so return values need not be explained. Still, for a no-annotation cancel tool with an undocumented required id, the description leaves the agent guessing about prerequisites and post-cancel state.

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

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

Schema description coverage is 0% for the single parameter, so the schema gives no meaning for 'confirmation_id'. The description does not compensate at all — it never mentions the parameter, its origin (presumably a preview_change call), or its format.

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 ('Cancel') and a precise resource ('a pending public-speaker change preview'), which an agent can distinguish from the generic nws_cancel_change and from nws_public_speaker_commit_change. It stops short of naming those siblings explicitly, so it is clear but not fully 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?

'Cancel a pending ... preview' implies the precondition that a preview must exist, and 'without remote changes' implicitly contrasts with the commit sibling. However, there is no explicit statement of when to prefer this over nws_cancel_change or where the confirmation_id must come from.

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?

No annotations are provided, so the description carries the full burden. 'List' implies a read-only retrieval, but nothing is said about whether authentication is required, whether the result is scoped to the caller's congregation, or how many circuits come back.

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

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

A single front-loaded sentence with no filler. It is well sized for a zero-argument list tool, though it could have used one more clause to distinguish it from its siblings.

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

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

An output schema exists, so return shape need not be explained, and the zero-param signature is simple. Still, the phrase 'this congregation' is unexplained — an agent cannot tell whether that context is implicit from the session or supplied by a prior call such as nws_public_speaker_congregations.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies since no parameter semantics are needed.

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

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

States a specific verb (List) and a specific resource (public-speaker sharing circuits), which is clearly a retrieval operation. It does not, however, distinguish itself from the closely named siblings nws_public_speaker_congregations and nws_public_speaker_connect, leaving the boundary between circuits and congregations implicit.

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

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

There is no statement of when to use this versus the other public-speaker tools, no prerequisites, and no exclusion criteria. The only hint is the phrase 'associated with this congregation', which implies scoping but never says how that association is established.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses optimistic concurrency ('if nothing changed since') and single-change scope, but omits whether the commit is irreversible, what permissions are required, and how failures are reported.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action and the key precondition immediately.

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

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

An output schema exists, so return values need not be explained. However, for a mutation tool with no annotations and an undocumented required confirmation_id, the description is only minimally adequate and leaves out parameter origin and failure behavior.

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

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

There is one required parameter, confirmation_id, with 0% schema description coverage, but the description never names or explains it. 'Previewed public-speaker change' only indirectly hints at where the confirmation_id comes from, leaving the parameter semantics largely undocumented.

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

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

The description uses a specific verb ('Commit') and resource ('one previewed public-speaker change'), making the operation clear. It also implies the tool's role relative to preview/cancel siblings, but does not explicitly name alternatives or contrast them.

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

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

The phrase 'if nothing changed since' gives a clear precondition for use, implying the agent should commit only after a preview and only when the underlying state is unchanged. It does not explicitly name the preview or cancel alternatives or say what to do when the condition fails.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not state whether this is a read-only operation, whether authentication or elevated role is needed, what happens when circuit_id refers to an unapproved or non-public circuit, or whether results are paginated or limited in size. The adjective 'public' hints at a visibility filter, but that is never spelled out.

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

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

One sentence, front-loaded with the verb and resource, with no redundant or filler clauses. It is appropriately trim for a single-parameter lookup, though that brevity is also the source of the missing context elsewhere.

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

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

An output schema exists, so return-value structure does not need explaining, and there is only one parameter. What remains missing is the prerequisite chain (circuit must be approved and sourced from nws_public_speaker_circuits) and any note on filtering or permissions, which for a tool with zero annotations is a meaningful 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 0% and the single sentence adds no meaning beyond the schema: it does not explain circuit_id's format, its origin, or whether it is an internal ID versus a display name. With the schema-provided field name the only clue, an agent must guess how to obtain a valid value.

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

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

The sentence gives a specific verb (List) and a specific resource (public congregations) scoped to an approved public-speaker circuit, so it is immediately distinguishable from sibling list tools like nws_public_witnessing_candidates or nws_public_speaker_circuits. It stops short of naming those siblings as alternatives, so the differentiation is implicit rather than explicit.

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

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

The phrase 'in an approved public-speaker circuit' implies a prerequisite context: the caller must already have an approved circuit, presumably obtained from nws_public_speaker_circuits. But the description never states that prerequisite or names any alternative tool, so the agent has to infer the workflow.

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?

No annotations are provided, so the description carries the full disclosure burden. It does contribute the useful 'read-only' safety signal, but it never explains what 'connect' actually establishes (session state? scoping subsequent calls?), whether it is idempotent, what happens on an invalid circuit_id, or any 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?

A single, front-loaded sentence with no filler. It is efficient, though its brevity here reflects under-specification rather than economy of expression.

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

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

An output schema exists, so return values need not be described. However, for a stateful-sounding 'connect' operation with an undocumented required ID and zero annotations, the definition omits what an agent most needs: what the call sets up and what it requires to succeed.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter — yet it only implies circuit_id names a circuit without giving a format, ID convention, or where to look it up. This is a meaningful gap for a required identifier parameter.

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 verb ('Connect') and a resource ('public-speaker sharing circuit') with scope qualifiers ('read-only', 'one'), so the general intent is graspable. But 'connect' is ambiguous — it could open a session, load a context, or fetch a single circuit — and no sibling is named to contrast with, despite nws_public_speaker_circuits sitting adjacent in the list.

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

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

There is no indication of when this should be chosen over nws_public_speaker_circuits or nws_public_speaker_congregations, and no prerequisite such as authentication or how to obtain a valid circuit_id. The agent is left to infer the workflow entirely 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?

With no annotations, the description carries the full burden. It does usefully disclose the 10-minute expiry of the returned confirmation ID and flags that leave_circuit can remotely delete data. However, it never clarifies whether 'preview' is a strict dry-run for every action — sync_congregations_and_speakers reads like a real import — nor does it state required permissions or what happens when the confirmation window lapses.

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

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

Front-loads the purpose and the confirmation-ID return in one sentence, then enumerates actions compactly. The action list is dense with parenthetical parameter hints but every clause carries information; no filler.

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

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

An output schema exists, so return values need not be described. Still, for a 5-parameter, zero-coverage, unannotated mutation-adjacent tool, an agent is left without the required circuit_id's meaning, without confirmation that the listed actions are the full valid set (the schema declares action as a plain string with no enum), and without clarity on which actions are safe reads versus side effects.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for circuit_type (primary or guest), congregation_id (used with approve/deny) and remotely_delete_data (scoped to leave_circuit on the approved primary circuit), but leaves the required circuit_id completely unexplained and doesn't say which parameters each action requires versus ignores.

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 ('Preview a public-speaker circuit change') and adds the distinctive outcome, a 10-minute confirmation ID. It implicitly separates itself from nws_public_speaker_commit_change / cancel_change through the word 'preview', but never names those siblings, so the differentiation is inferred rather than explicit.

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

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

The description implies the preview→commit flow by advertising a 10-minute confirmation ID, but gives no explicit when-to-use guidance, no statement that commit_change must follow, and no exclusions or prerequisite conditions for choosing this over the generic nws_preview_change or the public-speaker commit/cancel siblings.

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

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

With no annotations, the description carries the full burden, and "without writing" usefully discloses that no underlying data is mutated — valuable for a cancel operation. However it says nothing about whether the confirmation_id is invalidated, whether repeated calls are idempotent, or what state the preview is left in.

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, front-loaded with the verb and resource, with no filler. The only cost is that "without writing" is terse enough to be mildly ambiguous about what is actually discarded.

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

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

An output schema exists, so return-value explanation is not required, but for a cancel tool with no annotations and an undocumented required identifier, the description should at least state the confirmation_id's source and post-cancel effect. As it stands it is minimally sufficient to attempt a call but not to call it 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?

The single required parameter confirmation_id has 0% schema description coverage, so the description is the only place to explain it, and it does not — no origin (which preview tool produces it), format, or lifetime is given. The agent must guess where the value comes 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?

Names a specific verb (Cancel) and a specific resource (pending public witnessing administration preview), and the phrase "without writing" distinguishes it from the sibling nws_public_witnessing_commit_admin_change, which would apply the change. It is not explicitly contrasted with that sibling, but the operation 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 word "pending" hints that this follows a preview step, but the description never states when to cancel versus commit, nor names nws_public_witnessing_commit_admin_change as the alternative. There is no mention of what happens if the confirmation is stale, missing, or already consumed.

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?

No annotations exist, so the description carries the full burden; it does disclose the key behavioral trait that the operation writes nothing, which is valuable. But it omits whether cancellation is reversible, what happens to the abandoned pending import, and why a confirmation_id is needed for a non-writing action.

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

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

One short, front-loaded sentence with no filler; verb and resource lead. The only inefficiency is that 'without writing' is tacked on without elaboration.

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

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

An output schema exists, so return values need no explanation, and the operation is genuinely simple. Still, the unexplained confirmation_id and the unstated reversibility of a cancel action leave meaningful gaps for an agent to call 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?

There is a single required parameter, confirmation_id, with 0% schema description coverage, so the description must compensate. It never mentions the parameter at all, leaving the agent to guess what identifier is expected or where it comes 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?

States a specific verb (Cancel) and a specific resource (pending NWP app reservation import), which cleanly separates it from the sibling nws_public_witnessing_commit_app_reservation_import. The trailing clause 'without writing' is slightly ambiguous but does not obscure the purpose.

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

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

The word 'pending' implies the import must not yet be committed, which hints at when this applies. However, no sibling is named as the alternative and no prerequisites or state requirements are stated explicitly, so the agent must infer the commit/cancel routing.

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

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

With no annotations, the description usefully discloses that cancellation does not write remote data. However, it omits other important traits such as whether the operation is idempotent, what happens to the preview afterward, and whether authentication or ownership is required.

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

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

The description is a single compact sentence with the key action and safety property front-loaded. There is no wasted wording.

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 cancellation tool with a required confirmation_id and no annotations, the description is too thin. It does not explain the parameter's source or the post-cancel state, although the presence of an output schema reduces the need to describe return values.

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

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

Schema description coverage is 0%, and the description never mentions confirmation_id or explains where to obtain it. The sentence implies a confirmation identifier exists, but it adds essentially no semantic guidance for the sole required parameter.

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?

It states a specific verb and resource: cancel a pending shift-assignment preview. This distinguishes it reasonably from preview_assignment and commit_assignment, though it does not explicitly name sibling alternatives or the exact preview lifecycle stage.

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 'pending shift-assignment preview' implies this should be used on an already-created preview, but it never states when to choose cancel versus commit or what prerequisites must exist. Usage is inferable but not explicit.

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

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

No annotations are provided, so the description carries the full burden. 'Without writing' hints at a side-effect-free or discard-style operation but never explains what actually happens to the pending repeat, whether it is idempotent, whether it errors if the template is not pending, or what confirmation_id must contain.

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 no padding, so it is not verbose. But the final clause 'without writing' reads as an unresolved ambiguity rather than a useful qualifier, so brevity comes at the cost of clarity.

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

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

An output schema exists, so return values need not be explained. Still, for a cancel tool in a preview/commit/cancel triad, the description leaves out the workflow position, confirmation_id provenance, and failure conditions — key gaps with zero annotation 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?

The single required parameter confirmation_id has 0% schema description coverage, and the description adds nothing about it — not where to obtain it (presumably a preview call) nor what invalid values mean. With one undocumented parameter, the description must compensate and does not.

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

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

The verb and resource are identifiable ('Cancel a pending public witnessing template repeat'), which distinguishes it from the sibling commit/preview repeat-template tools. However, the trailing clause 'without writing' is opaque and undercuts an otherwise specific statement, leaving the agent unsure whether the tool actually mutates state or is a no-op.

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 instead of nws_public_witnessing_preview_repeat_template or nws_public_witnessing_commit_repeat_template, nor on prerequisites (e.g., that a preview must exist first). The agent must infer the preview→commit/cancel workflow from sibling names 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?

No annotations are provided, so the description must carry the full behavioral burden. "List" implies a read-only operation, but there is no discussion of permissions, whether this reflects current desktop state, ordering, pagination, or other relevant 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?

The description is a single front-loaded sentence with no wasted words. Its brevity is appropriate structurally, though the missing detail is better captured under other dimensions.

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?

Although an output schema exists, the description does not compensate for the absence of input schema descriptions or annotations. For a three-required-parameter tool in a cluster of public-witnessing siblings, it leaves too much about inputs and invocation context unexplained.

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

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

Schema description coverage is 0%, and the description does not define the required date, shift_id, and position parameters. It only alludes to a "shift position," leaving the meaning and expected format of the date and shift_id unclear.

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

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

The description uses a specific verb ("List") and resource ("people the desktop offers") scoped to a public-witnessing shift position. It is clear what the tool returns at a high level, but it does not explicitly differentiate itself from nearby siblings such as schedule, reservations, or assignment-preview 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?

There is no guidance on when to use this tool versus alternatives like nws_public_witnessing_schedule or the assignment preview/commit tools. The intended usage is only implied by the tool name and the word "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?

No annotations are provided, so the description must carry the full behavioral burden. It indicates a mutating commit action but does not disclose permanence, permissions, idempotency, confirmation expiry, or what side effects committing the previewed change has.

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

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

The description is a single sentence with no filler and is front-loaded with the core action. Every word contributes to identifying the operation.

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 output schema is present, so return values need not be explained. Still, for a mutation tool with no annotations and an undocumented required confirmation_id, the description should say more about how to obtain that ID and what the commit does.

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 single parameter has 0% schema description coverage, and the description never mentions 'confirmation_id' or explains where it comes from. The word 'previewed' hints at a preview confirmation flow, but the parameter's meaning and source remain implicit.

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

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

The description states a specific verb ('Commit') and resource ('previewed public witnessing location, shift, or template change'), which is clearer than a generic update. It broadly distinguishes this tool from preview and cancel siblings, though it does not explicitly name the preview tools whose output it commits.

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

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

The word 'previewed' implies this tool should be used after a preview step, giving some usage context. However, it does not explicitly say which preview tool to use first, nor when to choose this over commit_repeat_template or commit_app_reservation_import.

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

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

With no annotations, the description carries the full burden. It does disclose two non-obvious behaviors: this is a mutation ('Commit') and it enforces an optimistic-concurrency check ('if nothing changed since'). It omits what happens on a failed precondition, whether the operation is idempotent/retryable, and what the confirmation_id represents beyond the implied link to the preview.

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

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

A single front-loaded sentence with zero filler — the action comes first and the precondition second. It is tight to the point of under-specification, but that gap is better attributed to completeness than to verbosity.

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

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

An output schema exists, so return values need no explanation, and the concurrency precondition is stated. What is missing is lifecycle context: in a sibling landscape full of preview/commit/cancel triples, the description does not say this must follow the preview tool, nor how it differs from nws_app_commit_import, and leaves the sole required parameter unexplained.

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

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

Schema description coverage is 0% on the single parameter, confirmation_id. The description only implicitly ties it to the preview step via the word 'previewed'; it never says the value comes from the preview response, whether it expires, or how a mismatch is reported. The adjective 'previewed' is the only bridge the agent gets.

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

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

The description names a specific verb (commit) and a specific resource (a previewed NWP app reservation import), so the agent knows this finalizes a pending import rather than starting one. It does not explicitly name its siblings (preview_app_reservation_import, cancel_app_reservation_import, nws_app_commit_import), so the distinction is implied by the word 'previewed' rather than stated.

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

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

'if nothing changed since' gives a real precondition, implying this must be called after the preview step and only when the underlying data is unchanged — useful guidance that is not in the schema. However, it never states what to do when the condition fails (re-preview? cancel?) or names the alternative tools, so the when-not path 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?

With no annotations, the description carries the full burden; it does disclose one meaningful behavioral trait — the commit is conditional on underlying NWS data not having changed. It omits conflict/error behavior, whether the commit is reversible, and any permission or side-effect (e.g., notifications to publishers) information, which matters 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?

A single front-loaded sentence with zero waste; the condition is stated compactly after the core action.

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

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

An output schema exists, so return values need not be explained. But for a mutation tool with no annotations and an undocumented confirmation_id, the description should at minimum explain the provenance and lifecycle of the confirmation token and the consequence of a stale-data conflict; it does neither.

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

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

Schema description coverage is 0% for the single required parameter, confirmation_id. The description only hints it is tied to a prior preview ('previewed shift assignment') but never states where confirmation_id comes from, its format, or how long it is valid, so it does not compensate for the schema gap.

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

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

States a specific verb (commit) and a specific resource (one previewed shift assignment), plus a scoping condition that NWS data must be unchanged. This distinguishes it from the sibling preview_assignment and cancel_assignment, though it does not name those siblings 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?

The word 'previewed' implies this must follow nws_public_witnessing_preview_assignment, and the 'if NWS data is unchanged' clause implies a conditional/concurrency guard. However, the description never states what to do on conflict, whether to re-preview, or how the tool relates to its cancel counterpart, leaving the workflow only implied.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure and it says almost nothing. 'Commit' and 'previewed' imply an irreversible mutation that applies previously previewed changes, but the description never confirms irreversibility, whether it can be undone, whether prior state changes if the underlying data shifted since preview, or what auth/permissions are needed.

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

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

A single front-loaded sentence with no wasted words, so it is structurally clean. However, that terseness is achieved by omission rather than by efficiency — there is room to say more within one or two sentences without bloat.

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

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

An output schema exists, so return values needn't be explained, and the single-parameter schema is small. But for a commit/mutation tool with zero annotations, no sibling reference, and no explanation of confirmation_id, the description leaves out essentials an agent needs before invoking an irreversible write.

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

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

Schema description coverage is 0% and the single parameter 'confirmation_id' has no description in the schema or in the tool description. The description does not explain that this is the token returned by the preview call, which is the one thing an agent most needs to know to invoke the tool correctly.

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

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

The description names a specific verb (Commit) and resource (public witnessing template repeat) and the word 'previewed' implicates the preview/commit/cancel family it belongs to. It does not explicitly name the sibling nws_public_witnessing_preview_repeat_template, so an agent has to infer the pairing from the naming pattern rather than being told.

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?

'Commit a previewed ... repeat' implies the change must be previewed first, but it never says to call nws_public_witnessing_preview_repeat_template beforehand, never mentions nws_public_witnessing_cancel_repeat_template as the abort path, and gives no prerequisites. Usage is inferable from the preview/commit/cancel naming convention but not 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that results come from the local mirror and cover the given month plus the three previous months, but it does not state read-only behavior, authentication requirements, sync prerequisites, or pagination/response 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?

The description is two short sentences and is front-loaded with the tool's purpose. No sentence or clause is wasted.

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

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

Given one optional parameter and an existing output schema, the description covers purpose, time window, default behavior, and data source. The main remaining gap is that it does not mention whether a prior sync or authentication is required before the local-mirror report is accurate.

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

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

Schema description coverage is 0%, so the description must explain the sole parameter. It does so clearly by specifying the YYYY-MM format, that the default is the current month, and that the report window extends back three previous months.

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

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

The description states a specific verb and resource: reporting public-witnessing shift capacity and reservations per location. It also identifies the equivalent desktop Locations Utilization report, which distinguishes it from sibling schedule, reservation, and assignment 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 gives implied usage by saying it matches the desktop Locations Utilization report and covers a specific four-month window. However, it does not explicitly state when to use this tool versus siblings such as nws_public_witnessing_schedule or nws_public_witnessing_publishers_reservations.

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?

No annotations are provided, so the description carries the full burden. 'Preview' usefully signals this is a non-destructive check that does not persist changes. However, it doesn't state that a separate commit is required to apply the import, nor whether the preview output expires or is stateful.

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 efficient sentence with the verb and scope front-loaded. No filler, though it is perhaps terser than ideal given the absence of annotations.

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

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

An output schema exists, so return-value detail is not required. But for a preview step with no annotations, the description should at minimum mention the preview→commit pairing required to actually apply the import; that gap leaves an agent without the workflow context it needs.

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 no per-parameter semantics to convey. Baseline of 4 applies; nothing in the description contradicts or under-explains the empty schema.

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

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

States a specific verb ('Preview importing') and a specific resource ('reservations made in the NWP app into NWS data'). The 'preview' framing clearly separates it from its commit/cancel siblings. It does not name those siblings explicitly, keeping it just below a 5.

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

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

The word 'Preview' implies a dry-run step before committing, but the description never states when to use this instead of nws_public_witnessing_commit_app_reservation_import or the cancel variant. The workflow is inferred from naming convention 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?

No annotations are provided, so the description carries the full behavioral burden. It never states that the preview is non-persistent, that a subsequent commit is required to apply the assignment, what the preview returns, or whether permissions are needed — only the single word 'Preview' hints at the dry-run nature.

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 compact sentence with the assign/clear distinction front-loaded and no filler. It is efficient, though its brevity comes at the cost of the missing workflow and parameter context.

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

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

An output schema exists, so return values need not be explained, but for a four-parameter tool with no annotations and zero schema description coverage the definition is too thin. The preview→commit workflow and the meanings of date, shift_id, and position are 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 0% and none of the four parameter titles are self-explanatory. The description does explain person_id (a person id, or 0 to clear), but says nothing about date, shift_id, or what 'position' indexes, leaving three parameters undocumented in both schema and description.

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 (preview assigning/clearing) and resource (one shift position), and explains the two operating modes via person_id vs 0. It does not name the commit/cancel counterparts, so the agent must infer the preview-vs-commit relationship from the naming convention.

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

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

There is no statement of when to use this versus nws_public_witnessing_commit_assignment or nws_public_witnessing_cancel_assignment, nor whether a preview is a required step before committing. The only signal is the word 'preview' in the name, which is inferred 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?

With no annotations, the description does real work by disclosing the cascade side effect: 'Deleting a location or disabling a date also deletes the affected reservations, exactly as NWS Desktop does.' However it never states whether the preview persists anything, what the preview returns as validation feedback, or what permissions/errors to expect.

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 operation list and the destructive cascade warning comes last, which is the right ordering. Prose is tight with no filler, though the values enumeration is slightly dense in one 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?

An output schema exists so return values needn't be explained, but for a mutation-style preview tool with no annotations and 0% schema coverage, the description should still cover the preview/commit workflow and the unexplained top-level date and location_id parameters. It falls short on both.

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

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

Schema coverage is 0%, so the description must compensate, and it partially does by enumerating the operation values and the keys accepted in `values` (LocationID, CartNumber, AvailableFrom/To, Notes). But the top-level `date` and `location_id` parameters are never mentioned, and the description talks about a 'LocationID' inside values rather than the schema's separate location_id field, creating ambiguity.

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

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

The first sentence gives a specific verb (Preview) and resource (public witnessing location) with the full range of operations. It is distinguishable from the commit/cancel siblings in its family by the word 'Preview', though the description never explicitly contrasts itself with them.

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

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

There is no statement of when to call this versus the many commit/cancel siblings, nor any note that this is a dry-run that must be followed by a commit step. Usage is only inferable from the word 'Preview' in the name and first line.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a non-mutating preview and states a 1-8 week constraint, but it does not state whether anything is persisted, what the preview returns, or what happens to the preview object afterwards.

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 efficient sentence with the key constraint front-loaded and no filler. It is lean to the point of under-specification, but the phrasing itself wastes nothing.

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

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

An output schema covers return values, but for a 4-parameter tool with no annotations and zero schema description coverage, the description leaves core calling details – start_week format, id semantics, and preview lifecycle – unexplained.

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

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

Schema description coverage is 0%, so the description must compensate, and it only clarifies one parameter ('weeks' bounded 1-8). The format of the required 'start_week' string and the roles of 'location_id' and 'template_id' remain completely undocumented.

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 ('Preview repeating'), a specific resource ('public witnessing template'), and a scope ('one to eight weeks'). The word 'Preview' implicitly separates it from the sibling commit_repeat_template, though the description never names that sibling.

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

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

The word 'Preview' implies a dry-run before an actual commit, which is the intended workflow, but the description never says when to use this versus nws_public_witnessing_commit_repeat_template or how the preview is resolved.

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

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

With no annotations present the description carries the full burden, and it does deliver one genuinely valuable disclosure: deleting a shift cascades to all of its reservations. It says nothing about what a preview actually produces or persists, whether the result is committed later, or whether permissions are required for delete_all. One strong trait, several important gaps.

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

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

Purpose is front-loaded in the first clause and the remaining sentences are dense with usable facts — no filler. The operation list is embedded mid-sentence rather than broken out, which makes it slightly harder to scan, but nothing is wasted.

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

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

An output schema exists, so return values need not be described, and the cascade note covers the riskiest behavior. Still, for a five-parameter tool with zero schema coverage the description omits the preview lifecycle and the meaning of shift_id and source_location_id, leaving the agent to guess at call sequencing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for the two most complex parameters: it enumerates the operation values (create, update, duplicate, delete, delete_all, copy_from_location) and documents the values keys with formats (DayOfWeek 0–6, HH:MM or null, MaxPersons, KeyPersons 0–7). It leaves shift_id and source_location_id unexplained, though source_location_id is inferable from copy_from_location.

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 opening sentence names a specific verb (Preview) and resource (location shifts) and enumerates the five mutation intents it covers. However, it never contrasts itself with the commit/cancel counterparts in the sibling set (e.g. nws_public_witnessing_preview_location_change), so the agent must infer the preview-vs-commit split from naming convention alone.

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?

"Preview" implies this is a non-committing first step, which gives implied usage guidance, but the description never states when to pick this over the location/template preview siblings, nor that a matching commit is required afterward. No exclusions or preconditions 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?

With no annotations, the description carries the full burden. It does disclose one important behavior — that a save_week replaces an existing template of the same name — and the preview (non-committing) nature is conveyed by the name. But it says nothing about persistence, permissions, or the existence of a follow-up commit/cancel counterpart (none appears among the siblings), so the write workflow is ambiguous.

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 preview purpose followed by the operation breakdown. The parenthetical packing is slightly dense, but no sentence is wasted.

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

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

An output schema exists, so return values need not be explained, and the parameter mapping is solid. What is missing is the surrounding workflow: no annotations, no statement of whether committing requires a separate tool, and no mention of the apparent absence of a commit_template_change sibling — an agent could preview and then be stranded.

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

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

Schema description coverage is 0%, so the description must compensate — and it largely does, mapping all four parameters to their operations: operation (save_week | delete), name, week_start (must be a Monday), and template_id. It lacks type/format hints for week_start, but the semantic mapping is notably better than the bare schema.

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

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

The description gives a concrete verb+resource: previewing the save or delete of a week as a public witnessing template, and enumerates the two operation modes. It is clear what the tool does, though it does not differentiate itself from similarly named siblings such as nws_public_witnessing_preview_repeat_template.

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 which parameters belong to which operation (save_week needs name + Monday week_start; delete needs template_id), which is useful routing within the tool. However, it never states when to choose this over the repeat-template preview sibling, nor whether a commit step is expected afterward — usage is only implied by the word 'Preview'.

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