CrossPaste

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

Annotations declare the write/non-idempotent/non-destructive profile, and the description adds genuinely new behavioral facts: every call creates a new item even for duplicate content, the source is recorded as 'MCP', files are referenced by path rather than copied, and invalid input stores nothing. That is exactly the beyond-annotation context an agent needs.

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 purpose and the two key exclusions, then organized by parameter. It is long, but nearly every clause is a functional constraint rather than filler; only the extension enumeration is mildly list-heavy for a description block.

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

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

With no output schema, the description correctly covers the return contract (new item ID usable with get_paste_item) and the error path (invalid input stores nothing). Combined with the type-specific rules, an agent has everything needed 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?

Schema coverage is already 100%, so the baseline would be 3, but the description substantially exceeds it: per-type constraints (html must contain extractable text, rtf must start with '{\rtf'), the accepted image extensions, and the full color syntax list. These are validation rules the schema does not carry.

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?

Opens with a specific verb+resource ('Create a new item in the local clipboard history') and immediately scopes it against the obvious misreadings: does not touch the system clipboard and is not synced to other devices. An agent can distinguish this from get_paste_item and search_clipboard without reading any schema.

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

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

Clear context for when this tool applies (appending to CrossPaste history, not system clipboard) and it names get_paste_item as the consumer of the returned ID. It lacks an explicit 'use this instead of X' routing statement against siblings like search_clipboard, but the exclusion of system-clipboard semantics removes the main ambiguity.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context — the exact return content and that sizes are human-readable (e.g. 1.2 MB) — which matters since there is no output schema. It stops short of noting cost/pagination, but for a local no-arg stat call that is minor.

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 purpose, then safety, then return format, then the usage boundary — a sensible order with no filler. The enumeration of types is slightly long but earns its place by substituting for a missing output schema.

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

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

With no output schema, the description takes on the burden of describing returns and does so concretely (total count/size plus per-type breakdown, human-readable units). Combined with the usage boundary and annotations, an agent has everything needed 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?

Zero parameters, so the baseline is 4; the description reinforces 'no parameters', confirming no filtering or scoping is possible. Nothing further is needed or available.

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 (report) and resource (amount stored in local clipboard history), and the return shape distinguishes it from sibling readers like search_clipboard and get_paste_item. An agent knows exactly what this produces without opening a schema.

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

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

Explicitly scopes usage to 'an overview only' and names the two alternatives that cover other needs: search_clipboard for the items themselves and list_tags for tags. This is a textbook when/when-not 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?

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), and the description goes well beyond them with output shape per item type, the explicit exclusion of binary data, and the exact error conditions. This is real added disclosure rather than restating 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?

Purpose, ID sourcing, output format, errors, and the search fallback are packed densely and front-loaded, with no filler sentences. It is on the long side for a single-parameter getter, so it isn't maximally tight, but 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?

With no output schema, the description takes on the return-value burden and does so by type (text/html/rtf, links, colors, files/images) plus the header fields and error behavior. An agent can call this and interpret the result without further documentation.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value by explaining where valid IDs originate and enumerating the invalid cases ('missing, not a number, or matches no existing item'). It stops short of describing ID ranges or reuse 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 and resource ('Return the full content and metadata of one clipboard history item by its numeric ID'), which cleanly separates it from list/search siblings. The singular 'one ... item' plus the ID keying makes the retrieval-vs-search distinction 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?

Explicitly names the sources of the ID (search_clipboard results or add_to_clipboard) and gives a routing rule: 'Use search_clipboard first when the ID is not known.' That is a concrete when-to-use and alternative in one 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: no parameters, plain-text return shape, ordering follows user configuration, and the exact empty-state string. It also explicitly bounds the tool as non-mutating, reinforcing what the annotations only imply.

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 action and scope, then progressively adds return format, workflow hand-off, and negative boundaries. Every sentence carries distinct information with no filler or repetition.

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

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

With no output schema, the description compensates by describing the return format, ordering, and empty case, plus disambiguating what a tag is and how to use the result. Nothing an agent needs to call this correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4; the description correctly reinforces this with 'no parameters' and adds nothing misleading. There is no parameter surface left to document.

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

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

States a specific verb and resource ('List every tag defined in the local clipboard history') and defines what a tag is with a concrete example, so an agent can distinguish it from search_clipboard, get_clipboard_stats and the other siblings without opening any schema.

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

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

Gives explicit downstream usage: 'Pass a tag name to the tag parameter of search_clipboard to find the items carrying it', which routes the agent to the correct sibling workflow, and rules out mutation ('cannot create, rename or delete tags'). It stops short of an explicit when-not-to-use statement, so it is clear context rather than full 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?

Beyond the read-only/idempotent annotations, it discloses return shape and cardinality (up to 'limit' items, default 20, max 100, newest first, field list), matching semantics (every keyword must prefix-match a word in the searchable text), combination rules for 'type' and 'tag', and the notable error behavior for unknown type/tag instead of an empty list.

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

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

Front-loaded with purpose and read-only status, then return shape, then filtering rules, then sibling routing. Dense and mostly waste-free, though the limit/default/max clause and parts of the return-field list duplicate the schema and could be trimmed.

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

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

With no output schema, the description compensates by enumerating returned fields and ordering, plus the error mode for unknown type/tag and the handoff to get_paste_item for full content. An agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: prefix-match semantics across multiple keywords, the coupling of 'query' omission with listing recent items, and the pointer to list_tags as the source of valid tag names. It does not add much on 'limit' beyond repeating the documented default/max.

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 ('Search or browse the local clipboard history') and immediately scopes it with 'Read-only.' It is clearly distinguishable from siblings like get_clipboard_stats (counts), add_to_clipboard (writes) and get_paste_item (full content by ID), all of which are 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?

Gives explicit routing rules: omit 'query' to browse recent items, pass an ID to get_paste_item for full content, use get_clipboard_stats for counts only, use add_to_clipboard to create items, and get tag names from list_tags. When-to-use and when-to-use-something-else are both covered.

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