AttachPage

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered without the description. The description adds useful context about what is returned (paths, selectors, visible text, decisions), but nothing about auth, scope, or pagination behavior 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?

Two sentences with no filler, and the highest-value information (what is returned) is front-loaded. The second sentence largely duplicates the schema's status description, which is the only minor waste.

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

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

With a full output schema, the returns need not be spelled out, yet the description still orients the agent well; annotations cover safety and both params are documented. The one real gap is the absence of any routing guidance versus resolve_feedback among the siblings.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the "default all" note on status. The description's mention of open/resolved/all adds no syntax or meaning beyond the enum already in the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ("Read") and enumerates the resource contents precisely: recipient comments, page paths, pointed-at elements (selector and visible text), and approval/change-request decisions. An agent knows exactly what this tool retrieves. It never names a sibling (e.g. resolve_feedback) to distinguish reading from resolving, so it falls short of a 5.

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

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

The only guidance is "The status filter selects open, resolved, or all feedback," which restates the enum rather than telling the agent when to choose this tool over resolve_feedback or when to check feedback at all. No when-to-use, prerequisites, or exclusion conditions are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: a 20-file/256 KB cap, text or base64 encoding, and the notable edge case that an empty array returns a bounded manifest with no contents.

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

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

Three sentences, front-loaded with what is returned, then the optional mode and its boundaries. No filler or restatement of the name; every clause carries information an agent needs.

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

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

With only two parameters, full schema coverage, and an output schema handling return values, the description covers everything needed: the target resource, the optional file-retrieval mode, and its limits. Nothing required for a correct call is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: filePaths reads source files from the current version, and the limits plus encoding modes and empty-array semantics go beyond the schema's terse '[] returns only the file list'.

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

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

States a specific verb and resource ('Details for one page') and enumerates the returned fields (address, visibility, recipients, openers), which cleanly differentiates it from list_pages. An agent can tell this is a single-item detail fetch without opening the schema.

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

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

Usage is implied rather than stated: the description explains the optional filePaths mode but never names when to choose this over list_pages or get_feedback, nor any prerequisite beyond the schema's reference to a publish tool. No when-not guidance is offered.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the meaningful detail that the lookup is scoped to the calling agent's identity rather than an arbitrary account, but says nothing about failure behavior when no account is bound.

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, which is appropriately sized for a zero-argument identity lookup. Nothing is repeated from the title beyond the word 'profile'.

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

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

With no parameters and an output schema present, the description need not explain return values, and it correctly establishes the identity-scoping behavior. The only gap is that it never says when this lookup is warranted or what an agent should do with an unbound account.

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 scoring baseline the schema carries no parameter semantics to explain and there is nothing for the description to compensate for. The description correctly indicates the implicit input is the agent's own identity.

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

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

States a specific verb and resource: identifies the AttachPage account bound to the calling agent. An agent can grasp the purpose in one read, though it does not explicitly differentiate itself from siblings (which are all page/feedback operations, so overlap is minimal).

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 alternatives, no prerequisites, and no note about whether it must be called before other tools. The phrase 'connected to this agent' implies an identity-resolution use case but leaves the agent to infer it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the listing includes recipient and open counts, which is mild extra context, but says nothing about pagination, ordering, or scope of the result set.

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 zero filler. Every word earns its place.

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

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

For a zero-parameter read tool with full annotation coverage and an output schema, the description covers what is needed. Only a note on whether the list is paginated or filtered would make it fully complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

Specific verb and resource ('List the user's pages') plus the content of the listing ('recipient and open counts'), which distinguishes it from the singular get_page sibling. It never explicitly names an alternative, but the purpose is unambiguous.

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

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

No when-to-use or when-not-to-use guidance is given, and none of the siblings (get_page, send_page, publish_page) are referenced. The agent must infer that this is the enumeration counterpart to get_page from the name alone.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the irreversibility profile is partly covered; the description nonetheless adds real context beyond them by stating email is sent immediately, cannot be recalled, and that each recipient gets a fresh personal link. It still omits permission requirements and what happens when no active recipients exist.

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

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

Two sentences, no padding, and the core action plus its scope are front-loaded ahead of the caveats. Every clause carries information the agent can act on.

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

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

With an output schema present and rich annotations, the description only needs to cover scope and side effects, which it does. The remaining gap is the undefined term 'active recipients' and the behavior when none qualify, a minor omission for a two-parameter tool.

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

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

Schema description coverage is 100%, so both note and siteId are already documented in the schema. The description only restates that the note is optional and tied to 'what changed', adding no syntax or format details, so the baseline 3 applies.

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

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

The description names a specific verb (email) and a scoped resource (existing active recipients) tied to a page update, which is enough to separate it from publish_page and send_page in most cases. It stops short of naming the sibling it should not be confused with, so it lands at a clear-but-not-differentiating 4.

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 'that a page has been updated' implies the trigger context (use after a content change), but there is no explicit when-not guidance or routing to alternatives such as send_page or publish_page. Usage is implied rather than stated.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the critical lifecycle facts a caller cannot infer — the page is deleted after 48 hours unless claimed via claimUrl, and the agent must relay tellUser and the claimUrl. That is exactly the sort of consequence disclosure annotations cannot carry.

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

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

Front-loads purpose and the 48-hour deadline, then parameter guidance. The middle clause ('always relay tellUser and the claimUrl, and tell the user to keep the page before sending it to anyone') is a run-on that stacks two instructions, costing a little 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?

Complete despite an output schema being present: the description still surfaces the load-bearing obligations (relay tellUser, relay claimUrl, warn the user before sharing) that govern correct invocation, and the retention window is stated explicitly.

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

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

Schema description coverage is 100%, so slug, files, and siteName are fully documented in the schema; the description adds only the conditional rule for reminderEmail, which the schema already states. Baseline 3 applies since the schema does the heavy lifting.

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

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

Specific verb and resource ('Publish a public web page') plus a distinguishing constraint ('without an account or API key') that separates it from the sibling publish_page/publish_document tools, which presumably require auth.

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?

Clear usage context: use when publishing anonymously, with conditional instructions for reminderEmail ('If the user gives an email address, pass it as reminderEmail'). It never explicitly names publish_page or publish_document as the alternative for logged-in users, so the boundary 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?

Annotations flag destructiveHint=true and openWorldHint=true, and the description explains exactly why: "A siteId replaces the page at the same address" discloses the destructive replacement behavior. It also adds the 4 MB decoded size cap, the private-by-default visibility, and that the original is preserved for download – substantial context beyond the annotations.

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

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

Front-loaded with the core action and format list, then progressively adds size, rendering, and replacement details. Most sentences earn their place, though the middle sentence on PDF/slide/spreadsheet rendering is mildly descriptive padding rather than decision-critical information.

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

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

With an output schema present, return values need not be explained, and the description still covers formats, size limits, default visibility, replacement semantics, and the no-invitation behavior. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real constraints not in the schema: the 4 MB decoded limit and that content must be base64 bytes ("not a local path or URL" is reinforced). It also clarifies the siteId replacement semantics beyond the schema's short note.

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 (publish) and resource (file → browser-viewable page) and enumerates the accepted formats, so the agent knows exactly what the tool consumes and produces. It does not, however, name or distinguish itself from close siblings like publish_page or publish_anonymous_page, leaving that routing to inference.

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

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

"private by default" and "Does not send invitations" give clear contextual boundaries, implicitly steering the agent away from send_page/notify_recipients when no notification is wanted. There is no explicit when-not or named alternative, so the guidance is contextual rather than directive.

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

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

The annotations declare a destructive write, and the description goes well beyond them: it explains what gets destroyed (an existing page at the same address is replaced), the optimistic-concurrency behavior (stale edits are refused, changed page refused rather than overwritten), the preserveFiles retention semantics, the default visibility, and the auth requirement. This is exactly the kind of side-effect context an agent needs before a destructive call.

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

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

Five tight sentences, purpose front-loaded, each covering a distinct concern (identity, replace semantics, concurrency, visibility, auth) with no filler. Slight overlap with schema-described fields keeps it from being maximally economical.

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

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

For a destructive, open-world publishing tool, the description covers safety (destructive replacement), auth prerequisites, concurrency guardrails, visibility defaults, and asset retention. With an output schema present, return values need no explanation, so nothing material is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds causal semantics the schema does not: siteId's replace-at-same-address effect, the coupling of preserveFiles to baseDeploymentId, and the refusal-on-stale-edit behavior. It does not add file/encoding details, which is acceptable since the schema covers them.

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+resource ("Publish a web page") and adds the qualifier "as the connected user," which implicitly distinguishes it from the sibling publish_anonymous_page. It stops short of explicitly naming that sibling or contrasting with update_page/publish_document, so differentiation is inferable 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?

It states the prerequisites (authenticated AttachPage connection) and the conditions attached to specific parameters (siteId replaces, preserveFiles requires baseDeploymentId), which implies the update-in-place use case. However, it never says when to choose this tool over publish_anonymous_page, update_page, or publish_document, so routing guidance is left to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the mutation profile is covered. The description adds genuine context beyond that: the recipient sees the updated resolution status, disclosing an external visibility/notification side effect, and clarifies the default (true) versus reopen behavior.

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

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

Two sentences, no filler, with the primary action and its toggle stated up front. Every clause carries information (operation, inverse, recipient-visible effect).

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

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

With an output schema present, return values need not be described, and the description covers the mutation and its recipient-visible consequence. It is slightly thin on reversibility/permissions context for a destructive-flagged tool, but otherwise complete for this two-parameter operation.

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

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

Schema description coverage is 100%, and the schema already states that resolved:true (default) resolves and false reopens, plus that feedbackId comes from get_feedback. The description essentially restates the schema's boolean semantics rather than adding new meaning, so the baseline of 3 applies.

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

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

The description names a specific verb+resource pair (mark recipient feedback as resolved) and adds the inverse operation (reopen with resolved: false), so the agent can distinguish it from the read-only sibling get_feedback. It does not explicitly name any sibling, but the mutating purpose is unambiguous.

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

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

It implies when to use the tool by explaining the two modes (resolve vs. reopen via resolved: false), which is useful branching guidance. However, it gives no explicit when-not-to-use conditions, prerequisites, or routing to alternatives such as get_feedback for reading status.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is known. The description adds genuine value beyond that by naming the concrete consequence — the email is sent immediately and cannot be recalled — which tells the agent the effect is externally visible and irreversible. It stops short of mentioning required permissions or rate limits.

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

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

Two sentences, zero waste, and the operative content (what is sent to whom) is front-loaded ahead of the caution about irreversibility. Nothing is padded or repeated.

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 description covers the action plus its irreversible external effect. The only material gaps are unstated prerequisites (whether the page must be published first) and no cross-reference to notify_recipients, which is a plausible competing choice.

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

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

Schema coverage is 100%, so the schema already documents all four parameters including defaults (7 days, 0 = never expire) and the personal-link-per-recipient behavior. The description only restates 'optional message and access expiry,' adding no syntax or format detail beyond the schema. Baseline 3 applies when structured fields carry the semantics.

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

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

States a specific verb (email) and resource (personal invitations for a page) with the scoping detail 'to the specified recipient addresses.' It is clearly distinct from read tools like get_page and list_pages, though it does not explicitly differentiate itself from the nearby sibling notify_recipients, which an agent might reasonably confuse it with.

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 for sharing a page by email, but there is no explicit when-to-use statement, no condition distinguishing it from notify_recipients, and no stated prerequisites (e.g., must the page be published first?). The line about immediacy and irreversibility is a caution rather than routing guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds what is being mutated (name, slug, visibility), but does not disclose the consequences of a destructive mutation, e.g. that changing the slug breaks previously shared links or that visibility changes who can access an existing page.

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

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

A single front-loaded sentence that names the actions in the order of the schema fields, with zero filler or repetition. Nothing needs trimming.

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

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

With an output schema present, return values need not be explained, and annotations cover the destructive/write nature. The description accounts for all three mutable attributes, leaving only permission requirements and partial-update behavior unstated.

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

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

Schema description coverage is 100%, and the schema supplies format constraints (slug 3-40 lowercase letters/digits/hyphens) and enum meanings (private invitation-only vs public link). The description merely restates the same three fields, so the baseline 3 applies with no added semantics such as whether the update is partial or atomic.

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

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

The description pairs a specific verb (rename/change/switch) with a specific resource (page) and enumerates the three mutable attributes: name, slug, visibility. That is enough to distinguish it from the read-oriented siblings (get_page, list_pages) and the publish siblings, though it never names an alternative explicitly.

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

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

There is no when-to-use or when-not-to-use guidance. An agent is not told whether this requires ownership/admin rights, whether publish_page is the right call instead when the page does not yet exist, or what to do for a partial vs. full update.

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