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 for a mutation tool. It mentions an optional offline-save mode but omits permission requirements, behavior when the URL already exists, whether the operation is idempotent, and what the response contains.

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, stating the core action before the optional mode. It is efficient, though the brevity is part of why behavioral and contextual detail is thin.

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 7-parameter mutation tool with no annotations and no output schema, the description covers only the URL and a hint of offline saving, leaving tags, bundles, folders, and the offline format enum unexplained at the tool level. It is not sufficient on its own for an agent to call it confidently.

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

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

Schema coverage is 100%, so the schema already documents url, name, tags, bundle, folder, format, and save_for_offline. The description adds only a vague nod to offline saving, which maps to two of the parameters, so baseline 3 applies.

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

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

States a specific verb and resource ("Add a web URL into Keep It") that clearly distinguishes it from siblings like keepit_create_note or keepit_import_file. It does not explicitly contrast itself with those siblings, 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?

Usage is only implied by the verb; there is no statement of when to prefer this over keepit_import_file or keepit_create_note, nor any prerequisites or exclusions. The phrase "optionally saving for offline reading" hints at a mode but gives no guidance on when to choose 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?

No annotations are provided, so the description carries the full behavioral burden. It is a mutation tool, yet it says nothing about required permissions, what happens when the item is not editable, whether the append is additive at the end of existing content, or what the call returns on failure.

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

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

A single front-loaded sentence with the verb and target up front and no wasted clauses. It is efficient, though so terse that it leaves little else to work with.

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 full schema coverage and no output schema, the definition is minimally sufficient. However, as an unannotated mutation tool it omits failure behavior and preconditions that an agent would need to invoke it 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?

Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds only marginal meaning, notably that the appended content may be markdown, but gives no format, length, or positioning details beyond the schema.

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

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

The description gives a specific verb (append) and resource (text or markdown content) against a well-defined target (an existing editable Keep It item), which is clearly distinct from siblings like keepit_create_note or keepit_add_link. It stops short of explicitly naming those siblings or stating the boundary between append and create.

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: the word 'existing' signals the item must already exist, and 'editable' hints at a precondition, but the description never states when to choose this over keepit_create_note or keepit_add_link, nor any exclusion for non-editable items.

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 side effects, permissions, duplicate-name behavior, or what happens when bundle/folder are omitted. For a mutating creation tool with six parameters, a bare 'creates' statement leaves significant 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?

A single short sentence is efficient and front-loaded with the verb, but for a six-parameter creation tool with no annotations it is arguably undersized rather than truly concise. Nothing is wasted, but little is conveyed.

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 six parameters, no annotations, and no output schema, the description should at minimum explain default placement (bundle/folder are optional), tag handling, or the format options. Instead it provides only a restatement of the tool's name, leaving the agent to infer everything from the schema.

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

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

Schema description coverage is 100%, with every parameter documented in the schema (including the format enum and its markdown default), so the schema does the heavy lifting. The description adds no parameter meaning beyond naming the resource being created, which is the expected baseline when schema coverage is complete.

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

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

States a specific verb and resource: creating a Note or Markdown document in Keep It. It is understandable on its own, but it does not distinguish itself from close siblings like keepit_append_to_note or keepit_import_file, which an agent may conflate when deciding how to add content.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives. Nothing tells the agent whether to use this versus keepit_append_to_note for adding content to an existing note, or keepit_import_file for external files.

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 read, but does not disclose what happens when no item is open (null, error, empty result), whether it depends on the app being frontmost/focused, or any permission 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 that identifies the resource and its scoping qualifier with no filler or redundancy.

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 with no output schema, the description says what is fetched but not what is returned (item shape) or what occurs when nothing is open. Adequate for a simple accessor, but the edge-case and focus-dependency behavior an agent would want 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?

The tool takes zero parameters and the schema is trivially empty with 100% coverage, so there is nothing for the description to clarify. Baseline 4 applies for a no-parameter tool.

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 ('Get') and a clearly bounded resource ('the active or frontmost item currently open in Keep It'). The phrase 'active or frontmost' implicitly separates it from the sibling keepit_get_selected_items, but the description never names or contrasts that sibling explicitly, so the 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?

No when-to-use, when-not-to-use, or alternative guidance is given. With keepit_get_selected_items and keepit_get_item in the sibling list, an agent has to guess whether 'current' means frontmost window, last-edited, or something else, and when to prefer one accessor over another.

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 the breadth of the payload (metadata, tags, path, link, both text and markdown content), implying a read-only, non-destructive fetch, but it says nothing about permissions, behavior on missing/trashed items, or whether content may be truncated or large.

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 enumerates the payload without filler; every clause earns its place and 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?

For a one-parameter getter with full schema coverage and no output schema, the description adequately tells the agent what comes back, so return values need no further explanation. It stops just short of complete by omitting error/not-found behavior and any note on content size or truncation.

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 parameter at 100% schema description coverage, so the schema already explains 'unique ID or exact name'. The description adds no format, case-sensitivity, or ambiguity-resolution detail (e.g., what happens if name is not unique), so it does not exceed the schema baseline.

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

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

States a specific verb (Get) and resource (a Keep It item) and enumerates the returned fields (metadata, tags, file path, link, text/markdown content), which implicitly separates it from keepit_search_items and keepit_get_current_item. However, it never names a sibling, so an agent must infer the differentiation from the required lookup key 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?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as keepit_search_items, keepit_get_current_item, or keepit_get_selected_items. The description only says what it returns, leaving tool selection entirely 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the result depends on the live UI selection state ('currently selected'), which is non-obvious behavioral context, but it omits what happens when nothing is selected or whether the list can be empty.

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 appropriately sized for a trivial no-argument getter, though it could have used one clause to hint at return contents.

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 no output schema and no annotations, the description is minimally adequate. It does not describe the shape of the returned item list or the empty-selection case, which is the only remaining gap for such a simple tool.

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

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

The tool takes zero parameters, so per the baseline this dimension starts at 4. There are no parameter semantics for the description to clarify or compensate for.

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 ('Get') and resource ('currently selected items in Keep It'), making the operation unambiguous. It does not explicitly distinguish itself from close siblings like keepit_get_current_item or keepit_get_item, but the 'selected items' phrasing is distinct enough to be understood.

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 keepit_get_item, keepit_get_current_item, or keepit_search_items. Usage is only implied by the word 'currently selected', with no exclusions or conditions 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 burden of behavioral disclosure. It does not state whether the import copies or moves the file, what happens if the file is already in the library, whether tags/bundle/folder are optional, or what permission or access constraints apply.

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 padding. Nothing is wasted and the core action is immediately clear.

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 annotations and no output schema, the description must explain the mutation's effects and result, but it says nothing about what happens on success, whether it returns a reference to the imported item, or how errors (missing file, duplicate) are handled. Inadequate for a write 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 all four parameters are already documented in the schema. The description adds nothing beyond the schema's own parameter descriptions, 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 states a specific verb ('Import') and resource ('an existing file from disk into Keep It'), making the action unambiguous. It does not distinguish itself from siblings, but no sibling performs an import, so the operation is inherently distinct.

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 creating a note or adding a link, and no mention of prerequisites such as the file needing to already exist on disk. The agent must infer usage entirely from the name and description.

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 that the call is read-only, whether results are paginated or ordered, or what a returned bundle contains — "List all" implies completeness but nothing is confirmed.

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

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

A single short sentence with the verb front-loaded and no wasted words. It is efficiently structured, though its brevity reflects under-specification rather than disciplined economy.

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

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

For a simple zero-parameter list tool this is minimally adequate, but with no output schema and no annotations the description could reasonably say what a bundle is or what the listing returns. It leaves the domain concept 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?

The tool takes zero parameters, so there is no parameter semantics for the description to clarify. Baseline 4 applies; nothing in the description could add or subtract meaning 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?

States a specific verb and resource ("List all bundles"), making the operation immediately clear. It parallels sibling tools like keepit_list_folders and keepit_list_tags, but never explains what a "bundle" is in Keep It or how it relates to folders/tags, so it stops short of true sibling differentiation.

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

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

There is no guidance on when to call this versus keepit_list_folders, keepit_list_tags, or keepit_search_items. No prerequisites, filtering options, or exclusions are mentioned; the agent must infer usage entirely.

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, and it says nothing about read-only safety, pagination, ordering, or what a folder entry contains. For a no-argument listing tool the risk is low, but the description adds no behavioral context whatsoever.

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, which is appropriately sized for a zero-argument list tool. It is efficient but so terse that it borders on under-specification rather than earning a top score.

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 trivial zero-param lister with no output schema, the description is minimally adequate but leaves the return shape (what fields a folder has, ordering, whether nested folders appear) entirely unspecified.

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 schema defines zero parameters, so there are no parameter semantics to document and the baseline of 4 applies. The description correctly implies no arguments 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?

The description names a specific verb and resource ('List all folders') and scopes it to the Keep It app, so the agent knows exactly what it returns. It does not, however, distinguish itself from the similar list-style siblings (keepit_list_bundles, keepit_list_tags) or explain what a 'folder' is versus those other containers.

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 and no mention of alternatives, even though three sibling tools (keepit_list_bundles, keepit_list_tags, keepit_search_items) also enumerate entities. The agent must infer on its own when folders are the right enumeration to request.

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, but nothing is said about whether results are paginated, ordered, filtered, or whether any permissions are required. Only the minimal read implication is conveyed.

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

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

A single short sentence with no waste and the resource front-loaded. It is appropriately sized for a zero-arg list tool, though it is so terse that it borders on under-specification.

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

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

For a zero-parameter read tool with no output schema and no annotations, an agent knows what it does but not what it returns or when to choose it over keepit_manage_tags. Minimum viable, with clear gaps in behavioral context.

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 per the rubric the baseline is 4. There is nothing param-related the description needs to compensate for.

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 ('tags') with scope ('all tags in Keep It'), which distinguishes it from siblings like keepit_manage_tags or keepit_list_folders. It stops short of explicit sibling differentiation, but the action 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 guidance, no mention of when to prefer keepit_manage_tags or keepit_search_items, and no prerequisites. The agent must infer that this is a read-only enumeration tool.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not say whether unknown tags are auto-created on add, whether removing a non-existent tag errors, whether the operation is idempotent, or whether it requires the item to be unlocked/synced.

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. It is efficient, though its brevity reflects under-specification rather than tight editing of rich 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?

For a mutation tool with no annotations and no output schema, the description should explain side effects, tag auto-creation, and error behavior. None of that is present, so an agent cannot predict the result of a call.

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 item_id, add_tags, and remove_tags are all documented in the schema, giving a baseline of 3. The description adds no extra meaning beyond that, such as whether both add_tags and remove_tags can be supplied in the same call.

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 specific verbs (add/remove) and a specific resource (tags on a Keep It item), which clearly separates it from the read-only sibling keepit_list_tags. It is clear but does not explicitly name sibling alternatives or scope limits.

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 keepit_list_tags or keepit_get_item, no prerequisites, and no mention of how to discover existing tags before removing them. Usage must be inferred 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 behavioral burden, yet it discloses nothing beyond the facet list. It does not say whether multiple filters are ANDed or ORed, how results are ordered, how the default limit of 50 behaves, or whether the operation is paginated — all relevant for a search tool with six optional parameters.

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, and the resource is named before the facet list. It is efficient, though it is essentially a compressed restatement of the parameter set rather than added 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?

For a six-parameter search tool with no annotations and no output schema, the description is thin: it omits filter combination semantics, result ordering, and limit/default behavior. An agent could call it, but not confidently predict what the results or filter interactions will be.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema and the baseline is 3. The description's mention of query/folder/bundle/tag/favorite simply restates those same parameters without adding syntax, matching behavior, or interaction rules.

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 (search) and resource (items in Keep It) plus the available facets, so the agent knows this is a read-only query tool rather than a mutation or single-item fetch. It does not explicitly differentiate itself from siblings like keepit_get_item or keepit_get_selected_items, which is why it stops short of a 5.

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

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

There is no statement of when to use this tool versus keepit_get_item, keepit_get_current_item, or keepit_get_selected_items, nor any exclusion or prerequisite guidance. The only implied usage comes from the word 'search' itself.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose that removal goes to 'Deleted Items (trash)', implying a recoverable soft-delete rather than permanent destruction, which is genuinely useful. However, it omits permissions/auth requirements, whether the move can be undone or how, and any return/confirmation 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?

A single sentence that front-loads the verb and destination with zero filler. Nothing could be trimmed 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?

For a one-parameter tool with no output schema and no annotations, the description covers the core action but is thin on the details that matter most for a destructive operation: reversibility, required access, and what happens on success. Adequate but not complete.

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

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

Only one parameter (item_id) and schema description coverage is 100%, so the schema already fully documents it. The description adds no syntax, format, or sourcing detail beyond 'the item to move to trash', so the baseline 3 applies.

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

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

States a specific verb (move) and resource (item) plus the exact destination (Deleted Items/trash), so the action is unambiguous. It does not explicitly contrast itself with sibling tools, but 'trash' is distinct enough from the list/get/create/append siblings that an agent can place it correctly.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives (e.g., there is no permanent-delete sibling named, but also no statement about when trashing is appropriate). The agent must infer usage purely from the verb.

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