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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'Add a tag' without revealing whether the tag must already exist, if it creates the tag implicitly, whether the operation is idempotent, or what the response contains. The output schema provides some return info, but the mutation's side effects are unexplained.

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, concise sentence with no filler. It effectively communicates the core action and resource without unnecessary words.

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 this is a mutation tool with no annotations, the description is incomplete. It does not address prerequisites (e.g., tag existence), failure modes, idempotency, or any side effects beyond the basic action. The simplicity of the tool (2 params) partially offsets this, but the lack of behavioral context makes it insufficient for a safe 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 coverage is 100%, so the baseline is 3. The description does not add any extra meaning beyond the schema; it merely restates that a tag is added to a bookmark, which maps to tag_name and bookmark_id. No additional parameter details, formats, or constraints are provided.

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 the verb 'Add' and the resource 'a tag to an existing bookmark', distinguishing it from sibling tools like create_tag (which creates a standalone tag) and update_bookmark (which modifies bookmark fields). It is specific and 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 guidance is provided on when to use this tool versus alternatives. It does not mention that create_tag should be used to create new tags first, or that update_bookmark handles other bookmark modifications. The context is implied 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?

With no annotations provided, the description carries the transparency burden. It discloses the automatic 'readlater' tag, which is useful, but it does not mention other behavioral aspects such as whether the bookmark must already exist, whether it creates a new bookmark, or any side effects. The disclosure is partial but not misleading.

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 that is front-loaded with the primary action and includes a parenthetical clarification of the automatic tagging. There is zero redundant information, making it highly concise and well-structured.

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 the tool's simplicity, the description covers the essential behavioral context (automatic tagging, reading list target). An output schema exists, so return values need not be described. The only notable gap is whether the bookmark must already exist or is created as part of the operation, but overall the description is adequately complete for typical use.

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 each parameter (url, notes, title, description) is already documented. The description adds no additional parameter-level meaning beyond the automatic tagging behavior, which is not parameter-specific. Baseline 3 is appropriate.

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 the action ('Add a bookmark directly to your reading list') and distinguishes this tool from siblings like create_bookmark by specifying the reading list target and the automatic 'readlater' tagging. The verb+resource is specific and 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 description gives clear context: use this tool when you want to add a bookmark to the reading list with automatic tagging. It does not explicitly mention alternatives or exclusions, but the automatic tagging detail strongly implies the intended use case versus a generic bookmark creation.

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 of behavioral disclosure. It only states the core action and fails to indicate whether archiving is reversible, requires permissions, or returns the updated entity. No additional behavioral traits are disclosed.

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 very concise at one sentence, but it essentially restates the tool name and offers no additional structural value. While not verbose, the extreme brevity leaves out useful context that could be included without sacrificing 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?

For a mutation tool with no annotations and a vague description, contextual completeness is low. The description does not clarify side effects, return values, pre-conditions, or how archiving differs from other actions. This is insufficient for an AI agent to invoke the tool correctly without making assumptions.

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 input schema fully documents the single parameter (bookmark_id) with a clear description, and schema coverage is 100%. The description adds no additional semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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 ('Archive a bookmark'), clearly stating the action. However, it does not distinguish itself from sibling tools like unarchive_bookmark or delete_bookmark, nor does it explain the meaning of 'archive' in this context.

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 is provided on when to use this tool versus alternatives such as delete_bookmark or unarchive_bookmark. The description simply states the action without any context, prerequisites, or exclusions.

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 full responsibility for disclosing behavior. It states only that it checks and returns metadata, but does not mention whether the operation is read-only, what happens if the URL is not bookmarked, or any error cases. The safe verb 'check' implies read-only, but this is not explicitly stated.

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 concise sentence, front-loaded with the main verb and purpose. It is free of fluff and reads efficiently. While it is minimal, it communicates the core function without unnecessary words.

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 with one fully described parameter and an output schema, so the description does not need to explain return values. However, it lacks context about edge cases (e.g., archival status, URL normalization) and does not explicitly differentiate itself despite siblings. It is minimally adequate but not richly 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 input schema already fully describes the single parameter 'url' as 'URL to check,' giving 100% schema coverage. The description adds no extra context about formatting, validation, or URL requirements. With high schema coverage, a baseline of 3 is appropriate, even though the description does not enhance parameter understanding.

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 the specific action: 'Check if a URL is already bookmarked and get metadata.' This distinguishes it from sibling tools like get_bookmark (which likely retrieves by bookmark ID) and search_bookmarks (which searches) by focusing on URL-based existence checking. The verb 'check' and resource 'URL/bookmark' are 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 provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or recommend other tools for different scenarios. Users must infer usage solely from the purpose, but there is no explicit 'use this instead of...' context.

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 description only says 'Create a new bookmark in linkding,' which essentially restates the tool name. It discloses no behavioral traits such as authentication needs, auto-scraping behavior, or what happens on success or failure. With no annotations provided, the description carries the full burden, and it fails to meet it.

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, focused sentence with no extra words or repetition. It is front-loaded and easy to parse, earning a perfect score for conciseness.

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 tool with 9 parameters and an output schema, the description is far too minimal. It does not explain the bookmarking workflow, potential side effects like automatic title/description scraping, or how the response is structured. While the schema covers parameter details, the overall context of the tool's behavior is missing, making it incomplete for an agent to use effectively.

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 input schema has 100% description coverage for all 9 parameters, so the schema already provides full meaning. The description adds no parameter-specific information, but per the rubric, the baseline is 3 when schema coverage is high, and it does not need to repeat what is in 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 clearly states the tool creates a bookmark in linkding, using a specific verb and resource, and it is distinct from sibling tools like update_bookmark or delete_bookmark. However, it adds little beyond the tool name and does not elaborate on the bookmark's purpose or unique characteristics.

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 provides no guidance on when to use this tool versus alternatives, such as whether to use it for new bookmarks only or if other tools handle edge cases. It does not mention prerequisites or exclusions, leaving the agent without contextual decision-making help.

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 of behavioral disclosure. It merely states that a new bundle is created, but does not disclose side effects, permission requirements, uniqueness constraints, or response behavior. This is a minimal level of transparency for a mutation operation.

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 fluff, making it concise and front-loaded. However, it is extremely sparse and could benefit from a bit more explanatory context without becoming bloated.

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 comprehensive input schema and an output schema, the structured data already covers parameter meanings and return values. However, the description lacks domain context about what a bundle is or any behavioral nuances, leaving it functionally adequate but not thoroughly 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 input schema has 100% parameter description coverage, documenting all six parameters clearly. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 the operation 'create' and the resource 'bundle' in the context of linkding, which distinguishes it from siblings like update_bundle and delete_bundle. However, it lacks field-level specificity that would make it a 5, as it does not mention the required 'name' parameter or any other characteristics.

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 is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description is purely declarative and does not help an agent decide between create_bundle, update_bundle, or other sibling operations.

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?

There are no annotations, so the description must convey behavior. It only states that a tag is created, without disclosing whether duplicate tags are allowed, whether the operation is idempotent, or whether any special 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, focused sentence that efficiently conveys the core purpose. However, it is extremely brief and could include a bit more context 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?

The tool is simple with one parameter and an output schema, but the description does not mention behavior on duplicate tag names or any other edge cases. It is minimally adequate but leaves some questions unanswered.

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 fully documents the 'name' parameter with a clear description. The tool description adds no additional parameter semantics, but the baseline of 3 applies given the high schema coverage.

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 the action (create), the resource (tag), and the system (linkding), distinguishing it from sibling tools like create_bundle or create_bookmark.

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 is provided on when to use this tool versus alternatives, such as checking existing tags with get_tags or reusing an existing tag. The description only states the action.

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 full burden. It only says 'Delete' without disclosing whether deletion is permanent, requires authorization, or cascades to associated data.

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 wasted words. It is front-loaded and appropriately sized for a simple 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?

While the schema covers the parameter and output schema exists, the description lacks essential context such as distinguishing from archive_bookmark and clarifying the irreversible nature of deletion. This is particularly important given the sibling tools.

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 input schema describes the single parameter bookmark_id with a clear description. Since schema coverage is 100%, the description adds no additional parameter semantics; the baseline of 3 is appropriate.

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 the action (Delete) and the resource (a bookmark). It is distinct from siblings like archive_bookmark, which implies a different operation.

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 provides no guidance on when to use delete_bookmark versus alternatives like archive_bookmark or remove from reading list. It does not explain the difference between deleting and archiving, or the consequences.

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 full responsibility for behavioral disclosure. It only says 'Delete a bookmark asset,' which merely restates the tool's name and implies destruction but does not explain any side effects, permission requirements, or whether deletion is permanent. This is insufficient 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?

The description is a single, front-loaded sentence with no wasted words. It is concise, though it sacrifices informative content, which is reflected 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?

While the output schema exists and the tool has only two simple parameters, the description is extremely thin. It does not clarify the difference from delete_bookmark or explain the concept of a bookmark asset, leaving the agent without adequate context for correct usage.

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 input schema already provides descriptions for both parameters (asset_id and bookmark_id), so schema coverage is 100%. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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 the action ('Delete') and the resource ('a bookmark asset'), which distinguishes it from sibling tools like delete_bookmark or delete_bundle. However, it adds no detail about what a bookmark asset is or any scope, so 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?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions. It simply states the action without any decision-making support.

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 disclose behavioral traits. 'Delete a bundle' does not explain whether deletion is permanent, cascades to associated bookmarks, requires permissions, or is reversible. This is a significant gap for a destructive operation.

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, clear, and appropriately short sentence. Every word earns its place, with no fluff or redundancy, making it highly concise and easily parsable.

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 the tool is a destructive delete operation with no annotations, the description fails to convey critical context such as side effects or permanence. While schema and output schema cover parameters and returns, the lack of behavioral disclosure leaves the description incomplete for an AI agent.

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 for parameters is 100%, and the description adds no additional meaning beyond the schema's 'bundle_id' definition. The baseline of 3 applies because the schema fully documents the parameter, but the description provides no extra context.

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 'Delete a bundle' is a specific verb+resource statement that clearly distinguishes itself from sibling tools like create_bundle, get_bundle, and update_bundle. It unambiguously communicates the tool's core 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?

There is no guidance on when to use this tool, no prerequisites or alternatives mentioned, and no exclusions. The description only states the action without contextualizing it relative to other bundle operations or possible edge cases.

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 for behavioral disclosure. It only says 'Get a specific bookmark by ID' without mentioning error handling, whether the bookmark is returned regardless of status, permissions required, or any side effects. It lacks transparency about the tool's behavior beyond the trivial fact that it gets a bookmark.

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, concise sentence that is front-loaded with the key information. It contains no redundant text and every word earns its place for this simple 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?

For a simple read-by-ID tool with only one parameter, the description is minimally sufficient. However, given the presence of sibling tools like get_bookmarks, search_bookmarks, and check_bookmark, it lacks context about when this singular fetch is the right choice. The output schema likely explains return values, but the description does not help an agent disambiguate from related operations.

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 already covers the parameter fully: bookmark_id with description 'ID of the bookmark to retrieve.' The description adds no extra semantic meaning beyond what the schema states, so a baseline of 3 is appropriate.

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 'Get a specific bookmark by ID' clearly states the verb (get), the resource (bookmark), and the scope (specific by ID). It distinguishes from siblings like get_bookmarks (plural, likely listing) and search_bookmarks (query-based) by emphasizing singularity and direct ID access.

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: use when you have a specific bookmark ID and want that record. However, no explicit alternatives or exclusions are provided, and the description does not clarify when to prefer this over get_bookmarks or check_bookmark despite having many sibling 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?

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states 'Get', implying a read operation, but does not mention error handling, authentication requirements, or what happens if the asset is not found. It does not add any behavioral context beyond the tool's name.

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 of six words, with no fluff or repetition. It is front-loaded and easy to parse. However, it may be overly sparse for a tool with two required IDs, but conciseness itself is optimal.

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 a simple get-by-ID retrieval, and the output schema exists, so return values need not be described. However, the description fails to explain the relationship between bookmark_id and asset_id, and provides no usage distinctions from sibling tools. Given the context signals and schema, the description is minimally sufficient but has clear 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?

The input schema covers both parameters with descriptions (100% coverage), so the description needs to add little. However, it could have clarified the role of each ID or how they relate, especially since the description says 'by ID' without specifying which. The current description adds no semantic value 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 uses the specific verb 'Get' with the resource 'bookmark asset', clearly identifying a single-item retrieval operation. It indicates specificity ('specific', 'by ID') which distinguishes it from sibling tools like get_bookmark_assets (plural). However, the presence of two IDs ('bookmark_id' and 'asset_id') is not clarified, and no sibling tool is explicitly 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 provides no guidance on when to use this tool over alternatives such as get_bookmark_assets or get_bookmark. It does not state prerequisites (e.g., needing both bookmark_id and asset_id) or scenarios where this tool is appropriate. The only context is the verb 'Get', which is insufficient.

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 must disclose behavioral traits on its own. It merely states 'Get list' without detailing whether the operation is read-only, what happens for invalid bookmark IDs, or any resource restrictions. The lack of any side-effect or permission information leaves significant gaps, though the verb 'Get' does hint at a safe read operation.

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 that directly states the action and target without extraneous words. It is efficient and to the point.

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 the simplicity of the tool (one parameter, an output schema that likely defines asset structure), the description captures the core functionality. However, it does not disambiguate this list operation from the singular 'get_bookmark_asset' or mention any ordering/pagination behaviors, so it is adequate but not fully comprehensive.

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, bookmark_id, is already fully described in the schema as 'ID of the bookmark'. The description adds no new meaning beyond restating that the assets belong to a bookmark, so it offers no added value over the schema's existing documentation. Schema coverage is 100%, so the baseline score is appropriate.

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 the specific verb 'Get' and identifies the resource as 'list of assets for a bookmark'. The plural 'assets' distinguishes it from the sibling tool 'get_bookmark_asset', which targets a single asset. The purpose is clear and 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 guidance is provided on when to use this tool versus alternatives such as 'get_bookmark_asset' or 'search_bookmarks'. There are no exclusions, prerequisites, or context hints, leaving the agent without direction for tool selection.

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 present, so the description carries the full burden of behavioral disclosure. It states only that the tool returns a list, without mentioning pagination behavior, default filtering (e.g., archived=false), or that this is a read-only operation. This is minimal transparency for a tool with no 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?

The description is a single, focused sentence with no filler or redundant phrasing. It is front-loaded and perfectly concise, though it sacrifices depth for brevity.

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?

Despite having 7 parameters and an output schema, the description gives no overview of the tool's capabilities (e.g., filtering, pagination, archived bookmarks). This leaves the agent under-informed about the tool's full scope, especially in the context of many sibling tools.

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 input schema has 100% description coverage for all 7 parameters, so the baseline is 3. The description itself adds no parameter-level information, but the schema already provides detailed semantics for each parameter, including defaults and formats.

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 the action ('Get list') and resource ('bookmarks from linkding'), making the core purpose obvious. However, it does not distinguish this tool from the sibling 'search_bookmarks', which likely performs a similar listing function, 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?

No guidance is provided about when to use this tool versus alternatives like 'search_bookmarks' or 'get_reading_list'. The description offers no context for selecting this tool or excluding others, leaving the agent to infer usage from the schema.

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 of behavioral disclosure. It does reveal the return format (JSON string with specific fields) but does not explicitly state that the operation is read-only or safe, nor does it mention any error scenarios. However, the 'get' verb implies a non-mutating operation, and the return description is helpful.

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 brief, uses clear structure, and every word adds value—purpose then return format. 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?

For a zero-parameter tool with a straightforward output, the description fully conveys what the agent can expect: a JSON string with total, unread, archived, shared, and tag statistics. This is sufficient for correct invocation and interpretation, especially given the output schema 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?

The tool takes zero parameters, so the schema is empty. According to the baseline for zero-parameter tools, the description need not elaborate on parameters; it instead enhances understanding by listing the returned statistical fields.

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 line clearly states the tool's function: 'Get statistics about the bookmark collection.' This is a specific verb (get) and resource (bookmark stats), distinguishing it from siblings like get_bookmarks or get_bookmark by focusing on aggregate statistics rather than individual bookmarks.

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 its usage as a summary tool but does not explicitly specify when to choose it over alternatives such as get_bookmarks or search_bookmarks. There is no mention of exclusions or alternative recommendations, so the guidance is only implicit.

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 simply says 'Get', implying a read operation, but it does not disclose additional behavior such as what happens if the bundle is not found, whether the response is full or partial, or any constraints. This is minimal transparency.

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 concise sentence that conveys the essential purpose with no wasted words.

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 the tool's simplicity (one parameter, output schema available, clear ID-based retrieval), the description is sufficient for an agent to select and invoke it correctly. No additional context is necessary.

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 input schema already has 100% description coverage for bundle_id ('ID of the bundle to retrieve'). The description's 'by ID' adds no new meaning. Baseline 3 applies since schema covers parameters.

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 the action (Get), the resource (bundle), and the specificity (by ID). It distinguishes from the sibling get_bundles which lists bundles.

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 does not explicitly state when to use this tool versus alternatives like get_bundles. It is implied that this is for retrieving a single bundle by its ID, but no explicit guidance or exclusions are provided.

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 must carry the full burden of behavioral disclosure. It only states 'Get list of bundles' with no mention of read-only nature, pagination, ordering, rate limits, or side effects. This is a bare purpose statement, not behavioral transparency.

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 unnecessary words. It is maximally concise and to the point, earning its place without any fluff.

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?

Despite having a rich schema and output schema, the description lacks context about usage scenarios, pagination behavior, or how it relates to sibling tools. For a list tool with pagination parameters, this is a clear 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 input schema has 100% coverage with descriptions for both limit and offset, including defaults. The description adds no parameter information, but the schema already handles it, so the baseline of 3 is appropriate.

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 the tool retrieves a list of bundles from linkding, using a specific verb 'get' and resource 'list of bundles'. It implicitly distinguishes from the singular get_bundle, but does not explicitly differentiate from other list tools like get_bookmarks or search_bookmarks.

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 get_bundle for a single bundle or search_bookmarks for filtering. No exclusions or prerequisites are mentioned, leaving the agent without decision-making context.

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 transparency burden. It claims 'all bookmarks' but the schema includes a limit parameter with a default of 50, meaning it does not necessarily return all. This is misleading and fails to disclose pagination or result ordering, leaving behavioral 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?

The description is a single, front-loaded sentence that conveys the core purpose without unnecessary words. It wastes no space and is easily scannable.

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 the tool's simplicity (one optional parameter and an output schema), the description is mostly adequate but has a critical gap: the inconsistency between 'all' and the limit parameter. It also does not address ordering or return shape, though the output schema covers the latter. Overall, it leaves room for misinterpretation.

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 fully describes the limit parameter (maximum results, default 50), achieving 100% coverage. The tool description adds no additional semantic detail beyond 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 clearly states the tool retrieves bookmarks from the reading list, using a specific verb ('Get') and resource ('bookmarks') with a scoping tag (#readlater). This distinguishes it from sibling tools like get_bookmarks or search_bookmarks, which have broader or different scopes.

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 for retrieving reading-list bookmarks, providing clear context. However, it does not explicitly mention alternatives or exclusions, such as using get_bookmarks for all bookmarks or search_bookmarks for filtering, so it stops short of full 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 of behavioral disclosure. It only states 'Get list of tags' and does not disclose pagination behavior, read-only nature explicitly, authentication requirements, or any side effects. It adds minimal value beyond the tool name.

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, front-loaded with the action, and contains no filler. 'from linkding' is slightly redundant, but the overall size is appropriately compact for a simple list 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 tool is simple with an output schema and fully documented parameters, so the description doesn't need to explain return values. However, it lacks any behavioral context beyond the action, such as whether it returns all tags or respects pagination, and the absence of annotations leaves gaps 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?

Schema coverage is 100%, so the parameters limit and offset are already fully documented. The description adds no parameter information, but the baseline of 3 applies because the schema handles the semantics adequately.

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 ('Get') and resource ('list of tags'), making it clear what the tool does. It distinguishes itself from sibling tools like create_tag and add_tag_to_bookmark, though it doesn't explicitly contrast with any 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 description implies usage when a list of tags is needed, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context 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?

With no annotations provided, the description carries the full burden of explaining behavior. It discloses that the tool returns a JSON string containing profile and preferences, which indicates it is a read-only operation. However, it does not mention authentication requirements, whether it returns the current user or a specified user, or any potential error conditions. This is a basic level of transparency.

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 exceptionally concise, with two short sentences. The first states the action, the second outlines the return format. No wasted words.

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 no-parameter getter tool, the description is almost sufficient. The output schema exists and would detail the return structure, so the high-level summary in the description is adequate. However, it does not specify whose profile is retrieved, but the tool name implies the current user. Given the simplicity, the description is largely 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 has zero parameters, so there are no parameter semantics to document. Per the baseline guidance for 0 params, a score of 4 is appropriate, and the description does not attempt to add redundant information.

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 the tool's function: retrieving a user profile and preferences. This is distinct from sibling tools, which all focus on bookmarks, tags, or bundles, so 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?

The description does not explicitly discuss when to use this tool or contrast it with alternatives. However, the tool's name and the fact that no sibling tool handles user profiles imply its intended usage scenario. This is an implied usage, not an explicit guideline.

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 of behavioral disclosure. It simply repeats the tool's name and mentions 'advanced filters' without detailing how search works, what fields are searched, or any side effects/limitations. This adds minimal value beyond the tool's name.

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 unnecessary words. It is concise and scannable, though 'advanced filters' is slightly vague and could be more specific without adding length.

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?

Despite having a rich output schema and fully documented parameters, the description fails to provide necessary context about when to use this tool over siblings like 'get_bookmarks'. It does not clarify the scope of search (e.g., user's bookmarks vs. all) or any special behavior, making it incomplete for an agent to select 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?

The input schema provides 100% parameter description coverage, so the baseline is 3. The description's mention of 'advanced filters' adds no specific meaning beyond what the schema already documents for parameters like q, shared, and unread.

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 the specific verb 'Search' with the resource 'bookmarks' and adds 'with advanced filters', which clearly indicates the tool's function. However, it does not explicitly distinguish itself from the sibling 'get_bookmarks' tool, which might also search or list bookmarks.

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 provides no guidance on when to use this tool vs. alternatives such as 'get_bookmarks' or 'check_bookmark'. It implies usage through the phrase 'advanced filters' but does not state any exclusions or preferred contexts, leaving the agent to infer when this tool is appropriate.

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 present, so the description must carry the full burden of disclosing behavioral traits. It merely states 'Unarchive a bookmark' without mentioning effects (e.g., changes the archived flag), reversibility, permissions, or failure behavior. This is a minimal description that leaves significant operational unknowns.

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, clear sentence with zero wasted words. It is appropriately sized for a simple operation and easily parsed.

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 with one fully documented parameter and an output schema, but the description lacks context about preconditions (e.g., the bookmark must be archived), side effects, or error handling. Given the presence of the output schema and schema coverage, it is 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?

The single parameter 'bookmark_id' has a schema description ('ID of the bookmark to unarchive'), giving 100% schema coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies per the rubric.

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 'Unarchive a bookmark' uses a specific verb ('Unarchive') and a specific resource ('bookmark'), clearly distinguishing it from sibling tools like archive_bookmark. It unambiguously states the action and target.

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 explicit guidance on when to use this tool versus alternatives. However, the sibling 'archive_bookmark' makes the usage context implied: use this to reverse an archive. No exclusions or alternative naming are provided, so it only reaches an implied level.

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 full responsibility for behavioral disclosure. It only states 'Update an existing bookmark' without explaining partial update semantics, how null/omitted fields are handled, or any side effects on related data (e.g., tags). This is insufficient for a tool with 9 mutable fields.

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 short sentence with no wasted words, achieving maximum brevity. It is slightly repetitive of the tool name (update_bookmark) but otherwise compact and reasonably structured.

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?

Despite a rich schema with full parameter descriptions and an output schema, the one-sentence description leaves out essential context about update behavior—such as whether unspecified fields remain unchanged or are reset to defaults. The schema describes individual fields but not the overall merge/replace semantics, so the combination still lacks 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?

Schema description coverage is 100%, meaning each parameter already has a clear description. The tool description adds no additional parameter semantics, but the baseline of 3 applies because 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?

The description 'Update an existing bookmark.' clearly identifies the action (update) and resource (existing bookmark), distinguishing it from create_bookmark. However, it does not explicitly contrast with related sibling tools like archive_bookmark or add_to_reading_list, so it misses full 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 use this tool versus alternatives. The description does not mention that it is for modifying existing bookmarks as opposed to archiving, unarchiving, or adding to reading lists, leaving usage context entirely to the user.

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, and the description gives no behavioral context. It does not disclose whether updates are partial or full, what permissions are required, whether the operation is reversible, or any side effects on related data.

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 extremely short, but it is under-specified rather than concise. It merely restates the tool name with synonyms ('existing' adds no value) and provides no additional information, so it fails to earn 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?

This is a mutation tool with 7 parameters, no annotations, and an output schema, yet the description is a single bare clause. It completely fails to explain behavior, returns, or edge cases, making it inadequate for an agent to invoke 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?

The input schema covers all 7 parameters with descriptions, so the baseline is 3. The description adds no additional meaning beyond the schema, but it does not need to compensate for any schema gaps.

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 the operation (update) and resource (bundle). It is specific enough to distinguish from create/delete/get variants, though it does not explicitly mention any sibling 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?

No guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or why one would choose update_bundle over other bundle or bookmark tools.

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