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

With no annotations, the description carries the full transparency burden. It discloses specific computed stats, including the nuanced age-distribution phrasing ('sat untouched for years'), giving the agent insight into the output. It does not explicitly state read-only behavior, but the nature of a stats tool makes that implied.

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

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

Two sentences with no fluff. The first sentence lists what the tool returns, the second gives usage advice. Every word earns its place, and the informal tone ('pile') is concise and memorable.

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 stats tool with one optional parameter, the description covers the returned metrics and when to use it. It does not detail the exact return format (no output schema), but the listed metrics are sufficient for an agent to understand the tool's results. A minor gap is the lack of explicit read-only confirmation.

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 a thorough description of the 'source' parameter, including examples and semantics. The tool description adds no additional parameter detail, so the baseline score 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 provides a statistical overview: total count, per-source counts, age distribution, and top domains. This specifically distinguishes it from siblings like list_bookmarks (listing) and search_bookmarks (filtering), making the purpose 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?

'A good first call before triaging' gives a clear situational context for when to use this tool, implying it should precede more detailed exploration. It does not explicitly list alternatives or exclusions, but the guidance is sufficient for most agents.

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 burden. It discloses that the tool 'returns the file content' and clarifies the HTML format is 'importable browser HTML (Netscape format),' which is helpful. However, it does not mention any side effects, permissions needed, or limitations like browser detection time, so transparency is partial.

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 two concise sentences with no wasted words. It front-loads the key action and formats, then adds the return behavior and a user-friendly note. Every sentence earns its place.

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

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

For a simple read-export tool with two parameters, the description covers the purpose, output formats, and return value. It does not explain hardware/browser detection nuances or error handling, but given the absence of an output schema and annotations, it is reasonably complete. It does not mention using sibling tools like list_sources to obtain source IDs, but the schema fills that gap.

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 description adds semantic value beyond the schema by explaining that the output formats include 'markdown, csv, json, or importable browser HTML,' which clarifies the HTML option as Netscape format. The source parameter is already well-described in the schema, and the description reinforces its meaning without redundancy. Given the schema covers 50% but the description compensates for the format enum, this is above 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?

The description clearly specifies the verb ('Export') and the resource ('bookmarks from detected browsers'), lists the output formats, and distinguishes this tool from sibling list/search tools by focusing on file export. It leaves no ambiguity about what the tool does.

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 the tool is for exporting bookmarks to a file, with a note to 'save it wherever you like.' It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for selecting this tool over list/search variants.

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 full responsibility for behavioral disclosure. It explains the output format, the dead-link return values (`dead` or `unreachable`), and the caching behavior including how to bypass it via `refresh:true`. This gives the agent a clear mental model of the tool's runtime 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?

The description is three sentences, front-loaded with the core purpose, followed by usage guidance and caching details. Every sentence contributes new information without redundancy or 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 no output schema, the description effectively communicates what the tool returns (title, description, headings, excerpt, word count) and important edge cases (dead links, caching). For a tool with only two parameters, this is fully complete enough for an agent to select and invoke it correctly.

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

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

The schema has 100% parameter coverage with accurate descriptions, providing a baseline of 3. The description adds value by explaining that results are cached locally per URL and that `refresh:true` bypasses that cache, giving context to the `refresh` parameter beyond the schema's one-liner.

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: 'Fetch a bookmarked URL and return a short, structured preview' and lists exactly what the preview includes (title, description, headings, excerpt, word count). It distinguishes itself from sibling tools by emphasizing it returns a concise summary instead of raw HTML, making it unique among the bookmark management 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?

It explicitly says 'Use this only when a title/URL alone isn't enough to triage a bookmark,' providing both a when-to-use and a when-not-to-use condition. It also gives a concrete use case (dead links can be retired without guessing) which helps the agent decide between this tool and alternatives.

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 bears the full burden of behavioral disclosure. It mentions 'detected browsers' and pagination, offering some context, but it does not clarify default behavior (e.g., returns all bookmarks if no filter), the meaning of source filtering, or any prerequisites like running list_sources first.

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 concise and well-structured: two short sentences, front-loaded with the main action, and no unnecessary words. It efficiently communicates the core functionality.

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 description covers the basic listing function but omits significant details such as the source filter option, how 'detected browsers' relates to list_sources, and default pagination behavior. Given no annotations and no output schema, it is moderately complete but leaves important gaps for effective tool selection and 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 only 50% (folder and source described). The description adds 'folder filter' and 'pagination,' giving partial meaning to limit/offset, but it does not explain their specific semantics or mention the source parameter. This provides some compensation but not enough for full clarity.

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 ('List bookmarks') and the resource ('detected browsers'). It conveys the primary function effectively, though it does not explicitly distinguish it from sibling tools like search_bookmarks or recent_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?

No guidance is provided on when to use this tool versus alternatives. The description only mentions capabilities (folder filter, pagination) without indicating when one would choose this over search_bookmarks or other siblings.

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 burden. It accurately describes the detection scope and return value, and 'Detect' implies a non-mutating operation. Without explicitly stating side effects, it's sufficiently transparent for a read-only discovery 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?

Two sentences, no redundancy. The first sentence states the core function and scope; the second explains the output usage. Every word adds value.

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 tool without output schema, the description fully covers what is detected, what is returned, and how the results are used. No gaps remain.

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, and the description explains the output format (ids usable as `source`). Baseline for 0 params is 4, and the description adds value by indicating how the output will be consumed.

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 specific verb ('Detect') and resource ('bookmark source'), enumerating the exact browser profiles covered. It distinguishes itself from siblings by focusing on source discovery, not listing/searching 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 clarifies that the returned ids are usable as the `source` argument for other tools, implying this should be run first. It doesn't explicitly say when not to use it, but the use case is clear enough.

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 burden of behavioral disclosure. It adds useful context: reads from disk, auto-detects formats, and outputs 'clean JSON.' However, it does not mention error handling, file size limits, required permissions, or the structure of the returned JSON, leaving significant behavioral aspects undisclosed.

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 two sentences, front-loaded with the main action, and every sentence provides necessary information. It lists formats concisely without unnecessary detail.

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 has no output schema and no annotations, so the description should explain the return value. It only says 'clean JSON' without specifying the JSON structure (e.g., array of bookmark objects, fields included). While it covers input and auto-detection well, the lack of output format details leaves a gap for a parsing tool.

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

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

Schema coverage is 50% (only 'path' has a description; 'format' has an enum but no description). The description compensates by explaining auto-detection and listing the supported formats, which adds meaning to the 'format' parameter beyond just its enum values.

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: parsing a bookmark export file from disk into JSON. It specifically names the resource (bookmark export file) and the action (parse), and lists the supported formats, distinguishing it from sibling tools that list, search, or export 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 when to use this tool (for importing/parsing bookmark exports) and clearly distinguishes it from sibling tools that operate on already-parsed bookmarks. It does not explicitly state exclusions or alternatives, but the context is clear enough for an agent to select it appropriately.

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. It discloses time-range filtering and sort order, but does not explicitly state that it is read-only or side-effect-free. For a simple query tool, this is a moderate gap.

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 a useful usage example. Every word adds value, and the structure is front-loaded with the core action and scope.

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 no output schema and no annotations, the description provides adequate high-level context but lacks details on return format and parameter behavior beyond the time window. More specifics would improve 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 description only hints at the 'days' parameter via 'last N days', but does not explain 'limit' or 'source' filtering. With only 33% schema description coverage, the description fails to compensate for the undocumented 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 tool lists bookmarks added within a specified time period and orders them newest first. It distinguishes itself from siblings by focusing on recency, though it does not explicitly name alternative tools for other use cases.

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?

Provides a concrete use case ('what did I save this week?') that implies when to use the tool. Does not mention alternatives or exclusions, but the context is sufficient for a simple read-only listing 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: case-insensitivity, which fields are searched, and that all detected browsers are included. However, it does not mention read-only nature, result ordering, pagination, or possible performance implications, leaving gaps for a fully transparent behavioral profile.

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 conveys all core information without redundancy. It front-loads the action and resource, then adds key qualifiers (case-insensitive, fields, browsers). Every word earns its place, making it highly efficient.

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 search tool with 3 parameters and no output schema, the description is reasonably complete: it specifies search scope, case sensitivity, and the object being searched. It does not explain return values, but that is arguably implied by the name and common sense. The main omission is lack of usage guidance relative to siblings, which prevents a perfect score.

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 only 33% (source is described, query and limit are not). The description compensates partially by naming the searchable fields, which clarifies what the query parameter matches against. Yet it adds no semantics for the limit parameter, and the source filter is already described in the schema. Overall, the description adds some value but does not fully cover the missing parameter documentation.

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 a specific verb ('search') and resource ('bookmarks'), and explicitly defines the scope: case-insensitive matching across titles, URLs, folders, and tags in all detected browsers. This distinguishes it from sibling tools like list_bookmarks or recent_bookmarks, which serve different purposes.

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: use it when you need to find bookmarks by search terms. However, it does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or prerequisites. Clear context is provided by the search semantics, but no explicit contrast with sibling tools is offered.

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