goodnotes_copy_native_selection

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

Annotations only declare destructiveHint=false, readOnlyHint=false and openWorldHint=true; the description goes further by disclosing that it verifies source and saved visible appearance, that it does not certify exact text or hidden properties, and that differing backgrounds or overlaps can defeat verification. Those are real behavioral limits an agent cannot get from structured fields, though idempotency (operationId) and clipboard side effects go unmentioned.

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

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

Three tight sentences, front-loaded with the action, then verification scope, then failure conditions. No filler, though the phrasing is dense enough that the limitation clause could be clearer.

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 mutation tool with six parameters at 0% schema coverage and no output schema, the description covers verification semantics but omits parameter meaning, the purpose of operationId (likely an idempotency key), and any indication of what is returned on partial verification failure. It is a useful caveat paragraph rather than a complete definition.

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 six parameters, and the description documents none of them: x/y placement, destinationPage, selectionId, the destinationPath array (1-13 UUIDs) and the operationId key are all unexplained. Only a weak hint that the destination must be an 'allowed document' touches destinationPath, leaving the agent to guess required formats and meanings.

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 concrete verb (copy), a specific resource (guarded rectangular lasso selection), a destination (another allowed document) and the mechanism (native clipboard). This distinguishes it from generic copy siblings such as copy_page or copy_text_object, 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?

Usage is implied by 'another allowed document' and the note that different backgrounds or overlaps can prevent verification, which tells the agent when the call may fail. There is no explicit when-to-use versus copy_page / copy_text_object / copy_image_object guidance and no prerequisites such as needing a pre-existing selectionId.

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