Server Quality Checklist

Tool Scores

• create_bookmarkA
  3.5/5.0
  Behavior4/5

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

  Annotations already establish that this is a non-read-only, non-destructive mutation. The description adds a useful behavioral detail beyond annotations: metadata parsing is enabled, meaning the tool will parse metadata from the provided link. This does not contradict 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.

  Conciseness4/5

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

  The description is a single compact sentence with the core purpose front-loaded and no filler words. It is appropriately concise, though the brevity contributes to the parameter-semantics gaps.

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

  Completeness3/5

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

  The description is minimally sufficient for a basic call because it states link is required and metadata parsing is enabled, while the output schema and annotations cover return shape and safety. However, with nine parameters and no explanations for most of them, the description is not complete enough for confident, richer usage.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description only addresses link and parse_metadata, both of which are already visible in the schema. The seven optional parameters (note, tags, cover, title, excerpt, important, collection_id) receive no semantic explanation, so the description fails to compensate for the low schema coverage.

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

  Purpose5/5

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

  The description uses a specific verb and resource ('Create a bookmark') that clearly separates it from the sibling operations list_collections, search_bookmarks, get_bookmark, and update_bookmark. It also adds the scoping constraints that link is required and metadata parsing is enabled.

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

  Usage Guidelines2/5

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

  There is no explicit guidance about when to use create_bookmark versus update_bookmark, or when not to use it. The only usage clue is implied by the verb 'Create' and the statement that link is required; no alternatives or exclusions are mentioned.

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

• search_bookmarksA
  4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint and openWorldHint. The description adds genuinely useful behavioral details beyond annotations: collection_id 0 means all bookmarks, page numbering is zero-based, and default ordering differs between searches (relevance) and listings (newest first). This is valuable non-obvious context.

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

  Conciseness5/5

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

  Three compact sentences, no filler, and the most important information is front-loaded. Every sentence adds functional value.

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

  Completeness3/5

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

  The description covers the most important defaults and scoping behavior, and the output schema handles return-value expectations. However, with six optional parameters and no schema-level descriptions, the lack of query syntax details and nested/per_page semantics leaves the tool only moderately complete for an agent.

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

  Parameters2/5

  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. It explains collection_id and page, and hints at sort behavior, but the query parameter is only referenced as 'native Raindrop.io syntax' without elaboration, and nested and per_page are left completely unexplained. The description only partially compensates for the missing schema descriptions.

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

  Purpose5/5

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

  The description names the resource ('bookmarks') and the two modes ('List' or 'search') with a specific verb. It is clearly distinguishable from sibling tools like list_collections and get_bookmark, even without reading their schemas.

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

  Usage Guidelines4/5

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

  The description gives clear context for when the tool is appropriate: listing bookmarks or searching them with Raindrop.io syntax. It does not explicitly contrast with siblings or state when not to use it, but the intended use cases are unambiguous.

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

• update_bookmarkA
  4/5.0
  Behavior3/5

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

  Annotations already establish that this is mutating and destructive, so the description need not restate that. It adds the important behavioral trait that unspecified fields are left untouched and that the operation targets exactly one bookmark. It does not go into null-clearing semantics or side effects, so it provides modest added transparency 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.

  Conciseness5/5

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

  One short sentence, front-loaded with the verb and scope, with no filler. It earns its single sentence.

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

  Completeness4/5

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

  Given the output schema and annotations, the core call contract is mostly covered: target by bookmark_id, update only supplied fields, one bookmark. However, with a 10-parameter schema and 0% description coverage, a bit more detail on null-clearing and parameter interactions would make it fully self-sufficient.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description must supply the key semantics; it does supply the crucial 'only supplied fields' rule, which clarifies why optional defaults don't mean all fields are set. Individual parameter names are mostly self-explanatory, but there is no explanation of ambiguous values like explicit null versus omission or what reparse_metadata does.

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

  Purpose5/5

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

  The description uses a specific verb ('Update') with a clear resource ('bookmark') and a precise scope: only the fields the caller supplies, and only one bookmark. This differentiates it from create_bookmark, get_bookmark, and search_bookmarks without needing the parameter schema.

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

  Usage Guidelines4/5

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

  The wording clearly situates the tool as the modification path for an existing bookmark, versus listing/searching/getting or creating. It does not name an alternative explicitly or state exclusions, but the partial-update phrasing gives the agent the relevant condition for choosing it.

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

• get_bookmarkA
  4.1/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true, so the safe-read nature is covered. The description adds the 'positive ID' constraint, but discloses no additional behavioral traits such as not-found behavior or response characteristics. This is adequate but not rich.

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

  Conciseness5/5

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

  A single concise sentence with no wasted words. The core action is front-loaded, and the identifying constraint is included efficiently.

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

  Completeness5/5

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

  For a simple one-parameter tool with an output schema and annotations covering read-only behavior, the description is complete. No prerequisites, side effects, or return-value explanations are necessary.

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

  Parameters4/5

  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. It does by explaining that bookmark_id is a Raindrop.io ID and must be positive, which adds meaningful validation context beyond the bare integer type in the schema.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Get one bookmark' by its 'positive Raindrop.io ID.' It clearly differentiates this from sibling tools like list_collections or search_bookmarks by specifying a single item lookup by ID.

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

  Usage Guidelines3/5

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

  The usage context is implied: use this when you need a single bookmark and already know its ID. However, the description does not explicitly state when not to use it or mention alternatives like search_bookmarks for finding bookmarks without an ID.

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

• list_collectionsA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description adds the nested-collection default behavior, which is useful, but does not disclose pagination, ordering, or collection scope beyond that.

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

  Conciseness5/5

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

  One sentence states the operation, resource, and the key behavioral default with no filler. The most important information is front-loaded.

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

  Completeness4/5

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

  For a simple one-parameter list operation with an output schema and read-only annotations, this description is nearly complete. It could mention what include_children=false returns or any pagination, but the current text gives enough context for correct invocation.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description carries the burden for the single parameter. 'Including nested collections by default' clarifies what include_children controls, adding meaning beyond the bare boolean schema.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and resource ('Raindrop.io collections'), and the nested-collections detail distinguishes it from the sibling bookmark tools. An agent can understand exactly what this tool returns.

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

  Usage Guidelines4/5

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

  The resource name makes it clear this is for collections rather than bookmarks, and the default-behavior mention signals the common use case. It does not explicitly name alternatives or state when not to use it, but the sibling context is sufficient.

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