Moodmark

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description's collision behavior adds genuine context that reinforces the idempotency claim. But it omits whether the description parameter is applied to a pre-existing collection, visibility, or auth requirements.

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

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

A single tight sentence with the core action front-loaded and the edge-case behavior immediately after. 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 two-parameter mutation with strong annotations and no output schema, the definition is adequate but thin. The unaddressed description parameter and the ambiguous return value ('returns the existing one') leave an agent guessing about collision semantics.

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

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

Schema description coverage is 0%, so the description must compensate and it largely doesn't. It mentions 'name' only through the collision clause, and the optional 'description' parameter is never referenced at all, leaving its purpose and limits unexplained.

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

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

States a specific verb and resource ('Create an empty collection') and adds a scope qualifier about name collisions. It doesn't explicitly contrast with siblings like list_collections, but the create semantics are unambiguous against the listing/update 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?

The parenthetical implies when the tool is safe to call (name collisions return the existing collection rather than erroring), which is a useful usage cue. However, there's no explicit guidance on prerequisites, when to prefer update_bookmarks/share_collection, or what happens on failure.

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?

Adds real context beyond the annotations: generation is cached on the bookmark, a refresh forces regeneration, and the tool is gated to Premium accounts. It does not discuss latency, cost, or what a non-premium call returns, so it falls short of a 5.

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

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

One front-loaded sentence opening with the verb and product ('Turn one saved reference into design.md'), followed by a compact list of deliverables and a trailing constraint. No filler.

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

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

With no output schema, the description carries the return-value burden well by enumerating the brief's sections. The only remaining gap is error/premium-denial behavior and rough output size.

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

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

Schema coverage is 100%, so both parameters are documented in the schema itself, including that bookmark accepts an id or URL and that refresh bypasses the cache. The description only implies the cache/refresh relationship and adds no syntax 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?

States a specific transformation ('turn one saved reference into design.md') and enumerates the exact output artifacts: palette roles, typography, layout, components, a paste-ready AI prompt, and CSS/Tailwind tokens. This is unmistakably distinct from the collection/bookmark-management siblings.

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 'one saved reference' framing and the 'Premium only' note establish when the tool applies, and the schema points to search_library as the source of the bookmark id. It stops short of naming a when-not condition or an alternative path for non-premium users.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without prose. The description adds useful content detail by stating that results include bookmark counts and links, but says nothing about ordering, completeness, pagination, or whether empty collections appear — modest added value beyond the 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?

It is a single short sentence with no filler, which is appropriately sized for a no-argument tool. It loses a little because it is a fragment rather than a front-loaded verb phrase, making it feel like a caption more than an instruction.

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

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

With no output schema, the description carries the burden of explaining return values; it does mention bookmark counts and links but omits any sense of result shape, ordering, or whether all collections are returned. For a simple read-only list tool this is adequate but with 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-level information is missing.

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 phrase 'The user's collections with bookmark counts and links' names the resource (collections) and hints at content (counts, links), but it is a noun fragment with no verb, so the 'list/retrieve' action is only inferable from the tool name. It also does not distinguish this from siblings like list_tags or search_library, which also enumerate library entities.

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

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

There is no statement of when to call this versus alternatives such as search_library or list_tags, and no preconditions or exclusions. The agent is left to infer usage entirely from the name and the phrase 'user's collections'.

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

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

Beyond the readOnly and openWorld annotations, the description adds that results are organized by category and that returned names are the authoritative allowed values for saving. It does not explain ordering, pagination, or exact return shape, but those gaps are modest for a simple read-only listing 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 two compact sentences with no filler, and the key validity constraint is front-loaded after the resource description. Every element contributes useful information for selecting and using the 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 zero-parameter, read-only listing tool with annotations and no output schema, the description supplies enough context to call it correctly: it names the resource, indicates categorization, and states the saving constraint. A little more detail about the returned structure would make it fully 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 clarify and the schema is effectively complete. The baseline for a no-parameter tool is 4.

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 identifies the resource as the user's tags grouped by category, with examples such as industry, style, and layout. It does not explicitly distinguish this listing operation from the sibling suggest_tags, 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?

It establishes a clear use case: these are the only names that can be applied when saving, implying the tool should be consulted before writing tags. It does not state exclusions or name alternatives like suggest_tags, so it is not a full 5.

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

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

Annotations already declare non-read-only, idempotent, open-world, non-destructive, so the bar is lower; the description still adds real substance by spelling out what gets captured (screenshot, title, favicon, fonts, tech stack), when the palette is extracted, the 50-URL batch cap, and that duplicates are skipped — the last concretely grounding idempotentHint=true. It stops short of saying what a save returns or what happens on partial failure.

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

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

Three tight sentences, with the primary action and target library front-loaded, followed by capture behavior, then operational limits. Every clause carries information: no restatement of the tool name and no filler.

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 five-parameter write tool with no output schema, the description covers what is stored, the batch ceiling, dedup behavior and collection auto-creation — enough to call it correctly. Return shape and authentication requirements are unaddressed, so it is not fully 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?

Schema coverage is 100%, so 3 is the baseline, but the description adds a constraint not present in the schema — the 50-URL cap on a single call — and explains that the target collection is created when missing, which clarifies the collection/create_collection pair. The urls-vs-items alternative is still only explained by 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?

States a specific verb and resource ('Save websites to the user's Moodmark library') plus an explicit scope modifier (optional collection). It's clear what the tool does, but it never contrasts itself with the closest sibling, update_bookmarks, so the agent must infer the boundary between saving new sites and updating existing 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?

Usage context is implied: 'optionally into a collection (created if missing)' and 'Up to 50 URLs per call' hint at how to batch. But there is no explicit when-to-use this vs update_bookmarks, and no guidance on when to pick the flat 'urls' form vs the per-site 'items' form beyond what the schema says.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — 'Returns newest first' — but says nothing about result shape, paging behaviour, or handling of zero matches, which matters for an all-optional-filter search.

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 tight sentences with no filler, and the identifying scope ('bookmarks the user already saved') is front-loaded ahead of the filter enumeration and return ordering.

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 five-parameter, zero-required, read-only search with no output schema, the definition covers what can be searched and the result ordering but leaves filter-combination semantics and match behaviour unaddressed — the one thing an agent could actually get wrong when invoking it.

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?

With schema coverage at only 20% (just `limit`), the description has to carry the load, and it partially does: it names the fields `query` scans (title, URL, note, tags, fonts, tech) and maps `color`, `tags`, and `collection` to their concepts. It still never explains how multiple supplied filters interact, nor the expected array format for `tags`.

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

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

States a specific verb and resource ('Find bookmarks the user already saved') and enumerates the search axes: text fields, colour family, tags, collection. The phrase 'already saved' implicitly separates it from the write-side sibling save_websites, though no sibling is named explicitly.

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

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

Usage is only implied by the filter list — an agent can infer 'use this to retrieve saved bookmarks' but gets no guidance on when to prefer it over list_collections, list_tags, or get_design_brief, and no statement about whether filters combine (AND vs OR) or which to reach for first.

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 annotations already declare this is a non-destructive, idempotent, open-world write. The description adds real context on top of that: the collection becomes publicly visible, access is read-only, and external viewers can vote. It stops short of saying whether the link can be revoked and how an agent would do that, which is the main residual gap for a tool that changes public exposure.

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 filler. The action and its effect come first, and the usage restriction is front-loaded in the second sentence where it is easy to apply before calling.

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

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

For a one-parameter tool with rich annotations and no output schema, this covers what the agent needs to decide to call it. The only missing piece is whether the response returns the public link itself, which would help the agent fulfill the user's goal of sending it to a client.

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 single collection parameter (name or id) is already fully documented in the schema. The description adds no further detail about accepted formats or resolution behavior, which is acceptable at this coverage level but is baseline rather than value-adding.

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

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

The description gives a specific verb and resource: it turns on the public, read-only link for a collection. It also states what recipients can do (browse and vote), which goes beyond the name and makes the effect unambiguous. No sibling tool overlaps with this action, so an agent can place it immediately.

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 second sentence is an explicit trigger condition: only call this when the user explicitly asks to share, and the parenthetical names the intended audience (a client). That is a clear when-to-use and when-not-to-use rule, not an implied one.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real context beyond them: the 10-item cap, the constraint that suggestions come from the user's own tags (not free-form), and that each comes with a short reason — effectively disclosing the return shape.

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, zero waste, with the core purpose and the limit front-loaded before the routing note. Every clause 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 one-parameter read-only tool with no output schema, the description covers purpose, cap, suggestion source, per-item reason, and the follow-up tool — enough to call it correctly. Only the exact return structure is left implicit.

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% and the single 'bookmarks' array is fully documented with ids-or-URLs and max 10. The description restates the cap but adds no new parameter detail, so the baseline 3 applies.

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

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

States a specific verb and resource: 'AI tag suggestions for up to 10 saved bookmarks, chosen from the user's own tags'. This distinguishes it from list_tags (enumeration) and update_bookmarks (mutation), which it names explicitly.

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

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

'Suggestions only; apply the ones that fit with update_bookmarks' clearly routes the write path to a sibling and tells the agent this tool does not mutate. No explicit 'when not to use' or prerequisites, but the alternative is named with its condition.

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

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

Annotations already establish that this is a non-read-only but non-destructive mutation. The description adds meaningful context beyond that by stating the edits are additive, that nothing user-set is removed, and that a missing collection will be created. It does not clarify repeat-call behavior despite idempotentHint=false, which is a minor 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 tight sentence that front-loads the additive-edit scope and follows with the concrete operations and non-destructive guarantee. Every clause earns its place with no repetition or filler.

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 four-parameter mutation tool with annotations and no output schema, the description gives enough to call it safely: additive-only behavior, non-destructive semantics, existing tags, and collection creation. Missing explicit return behavior or duplicate-append semantics is a minor gap rather than a blocker.

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%, and the schema itself documents bookmarks (ids or URLs, max 100) and add_tags (existing tag names, see list_tags). The description adds meaning for append_note and add_to_collection, including missing-collection creation, but does not clarify repeat-append behavior or the remaining parameter constraints, so compensation is partial.

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

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

States a specific verb (additive edits) and resource (saved bookmarks), then enumerates the supported operations: adding existing tags, appending a note, and adding to a collection. It distinguishes itself from save/create siblings by emphasizing edits to already-saved bookmarks, though it does not name a specific alternative tool.

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: call this to annotate or file bookmarks that are already saved, and the mention of existing tags points toward list_tags. However, there is no explicit when-to-use/when-not guidance and no reference to alternatives such as search_library, suggest_tags, or save_websites.

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