Server Quality Checklist

Tool Scores

• add_cardA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses two meaningful constraints: sequencing after Cursor Run and a prohibition on parallel execution. However, it skips other useful mutation traits like duplicate handling, idempotency, or what happens if the deck name does not exist.

  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 sentence that front-leads with the action and includes the most critical caveat. There is no filler or redundancy.

  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 add-card tool with a fully documented schema and output schema, the description covers the essential usage conditions. The only notable ambiguity is the phrase 'after Cursor Run,' but the constraint is explicit enough for a context-aware agent.

  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 100% and every parameter is described in the schema, so the baseline is appropriate. The description does not explain any parameter further, but the schema already provides enough information.

  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 ('Add') and resource ('a card to Anki'), making it immediately clear what the tool does. It also distinguishes the tool from siblings like 'edit_card', 'get_card', and 'list_decks' by the action it performs on a card.

  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?

  It provides explicit operational context: the tool should be used 'after Cursor Run' and must never be called in parallel with other tools. It does not name a specific alternative, but the action is unique enough among the siblings that no exclusion is really needed.

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

• edit_cardA
  4.2/5.0
  Behavior3/5

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

  The description reveals the mutation and the approval workflow, but with no annotations, it leaves behavioral details implicit: it does not state whether the edit is reversible, whether omitted/null fields are left unchanged, or what the tool does when multiple fields are supplied. Some side effects therefore remain underspecified.

  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?

  The description is compact, front-loaded with the core action, and every sentence provides a meaningful operational instruction. There is minimal waste and the key workflow is stated first.

  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 tool's simplicity, its output schema, and the fact that only one parameter is required, the description covers the essential workflow and constraints well. It could be more complete by clarifying the null-field behavior and whether the edit is permanent, but those are relatively minor gaps.

  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?

  The schema already documents each parameter concisely and with 100% coverage, so the baseline applies. The description adds little parameter-level meaning beyond 'call with new values' and the note that a specific card (#N) is being edited.

  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?

  Opens with 'Apply one approved edit,' immediately stating the verb, the resource, and that the action is a single mutation on an existing card. This clearly separates it from add_card (create), get_card/search_cards (read), and list_deck_cards (listing).

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

  Usage Guidelines5/5

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

  The exact invocation context is stated: 'Used during systematic deck review after the user approves a specific card (#N).' It also explicitly warns to revise when new context arrives and never call the tool in parallel with others, giving clear usage boundaries.

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

• list_deck_cardsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description must carry the safety burden. It does so by explicitly stating 'Read-only' and adding the unexpected constraint 'Never call in parallel with other tools.' It also implies deterministic ordering through 'numbered cards,' which is useful behavioral 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 short sentences deliver the function, use context, safety, and concurrency guidance with no redundant elaboration. Every sentence earns its place.

  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?

  The description, combined with the 100%-documented input schema and output schema, covers purpose, intended use, parameter semantics, and critical behavioral constraints. It could be slightly stronger by naming alternative sibling tools, but overall it is complete enough for an agent to invoke it correctly.

  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?

  All three parameters already have clear schema descriptions: limit includes default and max, offset explains starting index and pagination purpose, and deck_name requires the exact Anki deck name. The prose description doesn't need to add parameter details; it only reinforces the systematic-review framing.

  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 is verb-first and specific: 'List numbered cards in a deck' for systematic review. This clearly distinguishes it from sibling tools like list_decks, get_card, and search_cards by targeting cards inside a single deck.

  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?

  It states when to use the tool: for systematic review sessions and chat analysis of forms like verbs and declensions. The constraint 'Never call in parallel with other tools' is explicit, though it does not name specific sibling alternatives for say search vs. full-deck listing.

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

• list_decksA
  4.2/5.0
  Behavior4/5

  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, and it does well by declaring 'Read-only' and the serial-call constraint, both of which are critical for an agent to know and are not apparent from the schema. The output format is documented via the output schema, so the description does not need to cover that. A minor gap is that it does not mention behavior such as empty results or error conditions, but these are less critical for a read-only zero-arg tool.

  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?

  The description is three short sentences, each with a distinct purpose: scope, safety, and invocation order. It is front-loaded with the primary purpose and contains no filler, redundancy, or extraneous detail.

  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 zero-argument listing tool with an output schema, the description is nearly complete: it states the action, the scope, the read-only nature, and the parallel-call constraint, giving an agent everything needed to invoke it safely. The only missing piece is explicit navigation of sibling tools, but the phrase 'deck names only' makes that distinction inferable.

  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?

  The input schema has zero parameters, so there is no parameter meaning for the description to add beyond what the schema provides. The 0-parameter baseline of 4 applies. Nothing is left undocumented, and no param-level elaboration is needed.

  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 ('Anki deck names'), with the word 'only' clearly narrowing the scope to names rather than full deck objects. This cleanly separates the tool from siblings like list_deck_cards, get_card, and search_cards, which all operate on cards. The purpose is unambiguous and actionable.

  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 description provides a clear operational constraint ('Never call in parallel with other tools'), which is useful guidance for how to invoke the tool. However, it does not explicitly state when to choose this tool over its siblings, such as list_deck_cards for getting cards within a deck or search_cards for querying card content. The selection context is only implied through the phrase 'deck names only.

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

• get_cardA
  4.3/5.0
  Behavior4/5

  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 adequately states the read-only nature of the operation and adds a specific concurrency constraint, which goes beyond what is visible from the schema. A little more detail on behavior, such as outcome if note_id is invalid, would be helpful but is not critical.

  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?

  Two short sentences, each carrying important information: what the tool does, that it is read-only, and a critical concurrency limitation. There is no filler or repetition.

  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 single-parameter tool with an output schema present, the description plus parameter schema provide everything an agent needs to select and call it correctly. It explains the core action, side-effect safety, a concurrency restriction, and where to get the required identifier.

  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?

  The input schema covers the sole parameter note_id with a clear description of where the ID comes from (list_deck_cards or search_cards), so the description need not repeat it. The description itself adds no new parameter semantic precision beyond what the schema already provides.

  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 card's full content') and clearly distinguishes this from list/search tools by emphasizing it returns a single card's full content. The 'Read-only' qualifier further disambiguates from mutating siblings like add_card and edit_card.

  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: use this when you need the full content of a single card, and it explicitly warns against calling it in parallel with other tools. It doesn't explicitly name alternatives or conditions for switching to sibling tools, but the schema's parameter description points to list_deck_cards or search_cards as prior sources for note_id.

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

• search_cardsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the safety burden. It clearly declares 'read-only' for a search operation and warns against parallel usage. It doesn't describe return details or rate limits, but the availability of an output schema and the simple read-only scope mitigate the need for more.

  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?

  The description is front-packed and extremely lean: a clear purpose line, an alternative command, and a concurrency warning. Every word earns its place without redundancy.

  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?

  Even with no annotations, the description gives the agent everything needed to select and invoke the tool: purpose, alternative when to use others, concurrency restriction, and the parameter semantics are fully covered by the schema. The output schema existence further removes ambiguity about the return type.

  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 description coverage is 100%, so the parameters are already well documented with examples and defaults. The phrase 'verbs, tags, text' lightly reinforces the query intent but doesn't add new meaning beyond the schema's own examples. Baseline 3 is appropriate.

  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 ('Search') and resource ('notes'), and explicitly scopes the purpose to targeted lookups by verbs, tags, or text. It also differentiates itself from the sibling by naming list_deck_cards as the alternative for full deck walkthroughs.

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

  Usage Guidelines5/5

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

  It explicitly states when to use this tool (targeted lookups) versus a clear alternative (list_deck_cards for full deck walkthroughs). The additional constraint 'Never call in parallel with other tools' provides a decisive usage rule. This leaves little ambiguity about selection or invocation context.

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