anki-mcp

by ujisati

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity, as they are organized by resource type (card, deck, media, model, note) and specific actions, making it easy for an agent to differentiate between them. For example, card_suspend and card_unsuspend are clearly opposites, and note_addNote and note_addNotes handle single vs. multiple notes without overlap.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern with a resource prefix (e.g., card_findCards, deck_createDeck, note_updateNote), all using snake_case throughout. This predictable structure makes the tool set easy to navigate and understand at a glance.
Tool Count2/5
With 40 tools, the count is excessive for the Anki domain, likely overwhelming for agents and indicating over-fragmentation of operations. A more streamlined set of 10-20 tools could cover the same functionality without sacrificing completeness, making this borderline heavy and inefficient.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for all key Anki resources (cards, decks, media, models, notes), with no obvious gaps. It includes creation, retrieval, updating, deletion, and specialized actions like suspension and tagging, ensuring agents can handle full workflows without dead ends.
Average 3.2/5 across 40 of 40 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning a list of objects but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or pagination. For a tool that presumably fetches note metadata, this leaves significant gaps in understanding how it behaves operationally.
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, efficient sentence with no wasted words. It's front-loaded with the core action ('returns a list of objects'), though it could be more specific. The structure is clear but lacks elaboration that might be necessary given the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'information' includes, return format, or error cases. For a tool with one parameter but potentially complex output, this leaves the agent under-informed about how to interpret results.
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 schema already documents the 'notes' parameter as a list of note IDs. The description adds no additional meaning beyond what's in the schema—it merely restates that note IDs are provided. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns information for note IDs, which clarifies it's a read operation. However, it's vague about what specific information is returned ('information for each note ID') and doesn't distinguish from sibling tools like note_findNotes or note_getNoteTags. The verb 'returns' is clear but the resource scope is ambiguous.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions. With sibling tools like note_findNotes and note_getNoteTags available, the lack of differentiation leaves the agent guessing about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states this is a read operation ('Returns'), but doesn't disclose behavioral traits such as error handling (e.g., invalid card IDs), performance (e.g., limits on list size), or output format (e.g., what fields are included in the 'objects'). This leaves significant gaps for safe and effective use.
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 a single, efficient sentence that front-loads the key action and resource. There's no wasted verbiage or redundancy, making it easy to parse quickly while conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'information' is returned (e.g., card fields, status), how errors are handled, or any usage limits, which are critical for an agent to invoke this tool correctly without trial and error.
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%, with the parameter 'cards' documented as 'A list of card IDs.' The description adds no additional meaning beyond this, such as format examples (e.g., integer ranges) or constraints (e.g., maximum list length). Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns a list of objects') and resource ('information for each card ID provided'), making the purpose understandable. However, it doesn't differentiate this tool from potential siblings like 'note_notesInfo' or 'card_findCards', which might provide similar card-related information with different scopes or filters.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'card_findCards' (likely for searching cards) and 'note_notesInfo' (for note information), there's no indication of whether this tool is for bulk retrieval, specific metadata, or other use cases, leaving the agent to guess based on naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the return type but lacks critical behavioral details such as error handling, rate limits, authentication needs, or what happens if card IDs are invalid. This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain the return format beyond 'unordered array of note IDs', missing details like structure or error cases. For a tool with rich sibling context and no structured support, more completeness is needed.
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 schema fully documents the 'cards' parameter. The description adds no additional meaning beyond implying the mapping from cards to notes, but doesn't clarify semantics like format or constraints. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and the resource ('unordered array of note IDs for the given card IDs'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'note_findNotes' or 'note_notesInfo', which also deal with notes, so it misses full sibling distinction.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for use, or compare to siblings like 'card_cardsInfo' or 'note_findNotes', leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool 'suspends' cards and 'returns true on success', which implies a mutation with a boolean outcome. However, it lacks critical details: what 'suspend' means operationally (e.g., hides cards, pauses reviews), whether it's reversible, permission requirements, error handling, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap.
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 very concise—two short sentences that state the action and outcome. It's front-loaded with the primary purpose. However, the brevity comes at the cost of completeness, as it omits important contextual details. Every sentence earns its place, but more sentences would be beneficial for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool that suspends cards), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'suspend' entails, potential impacts, or error scenarios. The return value ('true on success') is mentioned, but without an output schema, more detail on failure modes or other return data would help. For a tool with behavioral implications, this is inadequate.
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 has 100% description coverage, with the 'cards' parameter documented as 'A list of card IDs to suspend'. The description adds no additional parameter semantics beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Suspends') and the resource ('the specified cards'), making the purpose immediately understandable. It distinguishes from sibling tools like 'card_unsuspend' (opposite action) and 'card_suspended' (likely a status check), though it doesn't explicitly mention these alternatives. The description is specific but could be more precise about what 'suspend' means 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.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., card IDs must exist), exclusions, or compare to siblings like 'card_unsuspend' or 'card_setSpecificValueOfCard'. The agent must infer usage from the tool name and context alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the 'cardsToo' argument requirement, which hints at a safety confirmation, but doesn't describe critical behaviors like whether deletion is permanent, requires specific permissions, affects related data beyond cards, or provides any response format. For a destructive operation, this is inadequate.
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 extremely concise with two sentences that directly address the core action and a critical parameter requirement. Every word serves a purpose with no wasted information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like permanence, error conditions, or response format, nor does it provide usage context relative to sibling tools. The high schema coverage doesn't compensate for these gaps in a mutation operation.
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 schema already documents both parameters fully. The description adds minimal value by emphasizing that 'cardsToo' must be true, but doesn't explain why or provide additional context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Deletes') and resource ('decks with the given names'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'note_deleteNotes' or 'media_deleteMediaFile', but the resource specificity is sufficient for clarity.
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?
The description provides no guidance on when to use this tool versus alternatives like 'note_deleteNotes' or general deletion tools. It mentions the 'cardsToo' argument requirement but doesn't explain why this tool is preferred over others for deck deletion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states this is a read operation ('Gets'), but doesn't mention potential errors (e.g., if the deck doesn't exist), authentication requirements, rate limits, or what the returned configuration object contains, leaving significant gaps for a tool that fetches data.
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 appropriately concise with two sentences that directly state the tool's function and return value. However, the second sentence ('Returns the deck configuration object.') is somewhat redundant with the first, slightly reducing efficiency, but overall it's well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a configuration retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the configuration object contains, potential error conditions, or how it integrates with sibling tools, making it inadequate for full contextual understanding.
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 description coverage is 100%, with the parameter 'deck' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't clarify if 'deck' refers to a user-defined name or system default), so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Gets') and resource ('configuration group object for the given deck name'), making the purpose understandable. However, it doesn't explicitly distinguish this from sibling tools like 'deck_deckNames' (which lists decks) or 'deck_saveDeckConfig' (which modifies configurations), missing 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.
Usage Guidelines2/5
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. For example, it doesn't mention if this should be used before modifying deck configurations with 'deck_saveDeckConfig' or in conjunction with 'deck_deckNames' to verify deck existence, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the return value (true/false on success/failure) but lacks critical details: whether this is a mutation (implied by 'Saves'), permission requirements, error conditions, or side effects. This is inadequate for a tool that modifies data.
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 two concise sentences with zero waste, front-loading the core action. However, it could be slightly more structured by explicitly stating this updates existing configurations, but it's efficient as-is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 and no output schema, the description is incomplete. It lacks information on permissions, error handling, what 'configuration group' entails, or how it differs from sibling tools. The return value is mentioned, but behavioral context is insufficient.
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%, with the schema fully documenting the 'config' parameter (including the requirement for an 'id'). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Saves') and resource ('configuration group'), distinguishing it from siblings like deck_createDeck (creates new decks) and deck_getDeckConfig (retrieves configuration). However, it doesn't specify that this is for updating existing deck configurations, which would make it more precise.
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?
The description provides no guidance on when to use this tool versus alternatives like deck_createDeck or deck_changeDeck. It doesn't mention prerequisites (e.g., that the config must already exist) or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the destructive action ('Deletes') but doesn't mention critical details like permissions needed, irreversibility, error handling, or impact on associated notes/cards. This is inadequate for a mutation tool with zero annotation coverage.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It fails to address behavioral aspects like safety warnings, return values, or error conditions, which are crucial for an agent to use this tool correctly in context with sibling tools.
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 has 100% description coverage, so the schema already documents the single parameter 'filename' adequately. The description adds no additional meaning beyond what the schema provides, such as file format constraints or path details, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes') and resource ('the specified file from Anki's media folder'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like media_getMediaFilesNames or media_storeMediaFile, which would require a 5.
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?
The description provides no guidance on when to use this tool versus alternatives, such as note deletion tools or other media operations. It lacks context about prerequisites, consequences, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool 'Gets a list of model definitions,' implying a read-only operation, but doesn't specify whether it requires authentication, how it handles errors, what the return format is, or if there are rate limits. This leaves significant gaps in understanding the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand quickly with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what 'model definitions' include, the return format, or any behavioral traits like error handling. For a read operation with no structured output information, more context is needed to be fully helpful.
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 has 100% description coverage, with the parameter 'modelNames' clearly documented as 'A list of model names.' The description adds no additional meaning beyond this, such as examples or constraints, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets a list of model definitions') and resource ('for the provided model names'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'model_modelNamesAndIds' or 'model_modelFieldNames', which also retrieve model-related information, so it lacks sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. There are no explicit instructions on when to prefer this over other model-related tools like 'model_modelNamesAndIds' or 'model_modelFieldNames', and no mention of prerequisites or exclusions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool adds a field but lacks critical details: whether this is a destructive mutation, what permissions are required, if there are rate limits, what happens on duplicate field names, or the response format. This is inadequate for a mutation tool with zero annotation coverage.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain behavioral aspects like error conditions, side effects, or return values, leaving significant gaps for an AI agent to understand how 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?
Schema description coverage is 100%, so the schema already documents all three parameters (modelName, fieldName, index) with descriptions. The description adds no additional meaning beyond what's in the schema, such as format constraints or practical examples, meeting the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds') and the target resource ('a new field to an existing model'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'model_modelFieldRemove' or 'model_createModel', which would require explicit comparison for a score of 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., model must exist), exclusions (e.g., cannot add duplicate fields), or refer to sibling tools like 'model_modelFieldRemove' for field deletion or 'model_createModel' for model creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool 'Gets' data, implying a read-only operation, but does not disclose behavioral traits like error handling (e.g., if the model name is invalid), return format, or any rate limits. This leaves gaps in understanding how the tool behaves in practice.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for its simple function, with no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what the returned 'list of field names' looks like (e.g., format, ordering) or address potential errors, which is insufficient for a tool with no structured output documentation.
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 description adds minimal semantic context by specifying that the parameter is for 'the provided model name,' which aligns with the schema's 100% coverage. Since the schema already fully describes the 'modelName' parameter, the description does not provide additional value beyond what is structured, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and resource ('list of field names for the provided model name'), making the purpose immediately understandable. However, it does not distinguish this tool from sibling tools like 'model_modelNamesAndIds' or 'model_findModelsByName', which reduces its differentiation value.
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?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites, such as whether the model must exist, and does not mention related tools like 'model_modelFieldAdd' or 'model_modelFieldRemove' for field management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states this is a removal operation, implying mutation, but doesn't cover critical aspects like whether this action is reversible, what permissions are required, how it affects existing data, or error conditions (e.g., if the field doesn't exist). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, direct sentence with zero wasted words—it front-loads the core action and target efficiently. Every word earns its place, making it easy to parse and understand quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), usage context, and output expectations, leaving the agent under-informed for safe and effective invocation in a real-world scenario.
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 has 100% description coverage, with clear documentation for both 'modelName' and 'fieldName'. The description adds no additional parameter semantics beyond what's in the schema (e.g., no format examples or constraints), so it meets the baseline of 3 where the schema does the heavy lifting without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Removes') and the target ('a field from an existing model'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'model_modelFieldAdd' (which adds fields) or other model-modification tools like 'model_updateModelStyling', leaving room for improvement in sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the model must exist), when not to use it (e.g., if the field is critical), or refer to sibling tools like 'model_modelFieldAdd' for adding fields or 'model_updateModelStyling' for other modifications, leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'modifies' implying a mutation, but doesn't describe permissions required, whether changes are reversible, error handling (e.g., if model doesn't exist), or rate limits. This is a significant gap for a mutation tool with zero annotation coverage.
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 a single, efficient sentence that front-loads the core action and resource. It wastes no words and is appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error cases, or return values, leaving the agent with insufficient context to use the tool safely and effectively.
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%, with the schema documenting that the 'model' parameter must include 'name' and 'css'. The description adds no additional parameter semantics beyond what's in the schema, such as format details for CSS or name constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('modifies') and target resource ('CSS styling of an existing model by name'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'model_modelStyling' or 'model_updateModelTemplates', which might handle related styling or template updates, leaving some ambiguity about when to choose this specific tool.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'existing model by name' but doesn't specify prerequisites (e.g., model must exist) or contrast with tools like 'model_modelStyling' (which might retrieve styling) or 'model_updateModelTemplates' (which updates templates). Without such context, the agent lacks clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'modifies' implying a mutation, but doesn't disclose behavioral traits such as required permissions, whether changes are reversible, error handling, or rate limits. This is inadequate for a mutation tool with zero annotation coverage.
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 a single, efficient sentence with zero waste. It's front-loaded and appropriately sized, making it easy to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, no output schema, and nested parameters, the description is incomplete. It lacks details on behavior, error cases, or what the tool returns, which are critical for safe and effective use by an AI 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 description coverage is 100%, so the schema already documents the single parameter 'model' with its required fields. The description adds no additional meaning beyond implying the model must exist, which is minimal value. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('modifies') and resource ('templates of an existing model'), making the purpose understandable. It distinguishes from sibling tools like model_createModel (creation) and model_modelTemplates (likely reading), but doesn't explicitly differentiate from model_updateModelStyling, which is similar but for styling rather than templates.
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., model must exist), when not to use it, or compare it to related tools like model_updateModelStyling or model_modelTemplates, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool adds tags but doesn't mention whether this is idempotent, what permissions are required, how duplicates are handled, or what happens on failure. For a mutation tool with zero annotation coverage, this leaves significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for this simple tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 no output schema, the description is insufficient. It doesn't explain what happens when tags are added (are they appended? merged?), what the return value might be, error conditions, or how this interacts with other note operations. The context signals show this is a straightforward tool, but the description should do more given the lack of structured metadata.
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 schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain tag format constraints beyond the schema's example or note ID validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds tags') and target resource ('to the specified notes'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like note_removeTags or note_getNoteTags beyond the basic verb difference.
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?
The description provides no guidance on when to use this tool versus alternatives like note_removeTags or note_updateNote. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool deletes notes, implying a destructive mutation, but doesn't disclose critical behaviors: whether deletion is permanent/reversible, permissions required, rate limits, error handling, or what happens to associated data (e.g., cards in Anki context). This is a significant gap for a destructive 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 a single, direct sentence with zero wasted words. It front-loads the key action ('Deletes') and resource, making it immediately understandable. Every word earns its place, and there's no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is inadequate. It doesn't cover behavioral aspects (permanence, side effects), error cases, or return values. Given the complexity of deletion in a system like Anki (where notes may link to cards), more context is needed for safe and effective use.
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%, with the parameter 'notes' clearly documented as an array of note IDs to delete. The description adds no additional meaning beyond the schema (e.g., format examples, constraints like minimum array length). With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes') and resource ('notes'), specifying it targets notes with given IDs. It distinguishes from sibling tools like note_addNote or note_updateNote by focusing on deletion. However, it doesn't explicitly differentiate from other deletion tools like deck_deleteDecks or media_deleteMediaFile, which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., note existence), exclusions, or compare to similar tools like note_removeTags or media_deleteMediaFile. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While 'Removes tags' implies a mutation operation, it doesn't specify whether this requires special permissions, what happens if tags don't exist on the notes, whether the operation is reversible, or what the response looks like. This leaves significant behavioral gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just one sentence that directly states the tool's purpose. There's no wasted language, repetition, or unnecessary elaboration. Every word earns its place in conveying the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 no output schema, the description is insufficiently complete. It doesn't address important contextual aspects like error conditions, what happens when tags aren't present, whether the operation is idempotent, or what the agent should expect as a result. The 100% schema coverage helps with parameters but doesn't compensate for the broader behavioral 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 description coverage is 100%, so both parameters are fully documented in the schema. The description doesn't add any meaningful semantic context beyond what the schema already provides about 'notes' being note IDs and 'tags' being a space-separated string. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Removes tags') and the target resource ('from the specified notes'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'note_addTags' or 'note_getNoteTags', which would require explicit comparison to achieve a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparison with sibling tools like 'note_addTags' or 'note_updateNote' which might also affect tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool modifies existing notes, implying a mutation, but lacks details on permissions, side effects, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 no output schema, the description is insufficient. It lacks details on behavioral traits, error conditions, and what the modification entails beyond basic field/tag updates, leaving significant gaps in understanding how to use the tool effectively.
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 has 100% description coverage, documenting the single 'note' parameter with its structure and required 'id'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('modifies') and resource ('fields and/or tags of an existing note'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'note_updateNoteFields' or 'note_addTags', which appear to handle similar operations, leaving some ambiguity about when to choose this tool over those alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools such as 'note_updateNoteFields' and 'note_addTags' available, there is no indication of specific use cases, prerequisites, or exclusions, leaving the agent without clear direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool modifies fields, implying a mutation, but lacks details on permissions, side effects, error handling, or response format. This leaves significant gaps for an agent to understand the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens on success or failure, what fields can be modified, or how it differs from similar tools, leaving the agent with incomplete context for safe and effective use.
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 has 100% description coverage, documenting the 'note' parameter thoroughly. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 without compensating or detracting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('modifies') and resource ('fields of an existing note'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'note_updateNote' or 'note_addNote', which limits its score to 4 rather than 5.
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?
The description provides no guidance on when to use this tool versus alternatives like 'note_updateNote' or 'note_addNote', nor does it mention prerequisites or exclusions. It merely states what the tool does without context, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool returns an array of card IDs but doesn't disclose behavioral traits such as error handling (e.g., invalid queries), performance (e.g., large result sets), or side effects (e.g., read-only operation). This leaves gaps for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the key information (returns array of card IDs) and includes a helpful example. There is no wasted verbiage, making it easy to parse quickly.
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?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter but lacks details on usage guidelines, behavioral transparency, and output specifics (e.g., format of returned IDs), leaving room for improvement.
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%, with the query parameter fully documented in the schema. The description adds minimal value beyond the schema by mentioning 'Anki search query' and providing an example ('deck:current is:new'), but it doesn't elaborate on query syntax or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('array of card IDs'), specifying it's for Anki search queries. It distinguishes from siblings like card_cardsInfo (which returns detailed card info) and note_findNotes (which finds notes rather than cards), though it doesn't explicitly name these alternatives.
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention when to prefer card_findCards over card_cardsInfo (for IDs vs. detailed info) or note_findNotes (for cards vs. notes), nor does it specify prerequisites like needing a valid query format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return value ('Returns true on success'), which is helpful, but lacks critical details: it doesn't specify what happens on failure (e.g., error handling), whether unsuspension is reversible, permission requirements, or rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps.
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 extremely concise (two short sentences) and front-loaded with the core action. Every word earns its place: the first sentence states the purpose, and the second adds critical behavioral information about the return value, with zero wasted text.
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?
Given the tool's moderate complexity (a mutation operation with one parameter) and no annotations or output schema, the description is minimally adequate. It covers the basic action and return value but lacks details on error conditions, side effects, and usage context. For a tool that changes card state, more completeness would be beneficial.
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%, with the single parameter 'cards' well-documented in the schema as 'A list of card IDs to unsuspend.' The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('unsuspends') and resource ('specified cards'), making the purpose immediately understandable. It distinguishes from sibling tools like 'card_suspend' by specifying the opposite action. However, it doesn't explicitly differentiate from other card modification tools like 'card_setSpecificValueOfCard'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., cards must be suspended first), when-not scenarios, or direct comparisons with sibling tools like 'card_suspend' or 'card_setSpecificValueOfCard' for card state management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool returns a list of filenames, which is helpful, but lacks critical behavioral details such as whether it's read-only, if it requires specific permissions, how it handles errors, or if there are rate limits. This is a significant gap for a tool with no annotation coverage.
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 two sentences that are front-loaded and efficient. The first sentence states the purpose, and the second specifies the return value, with no wasted words. It's appropriately sized for the tool's complexity.
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?
Given the tool has no annotations and no output schema, the description is incomplete. It covers the basic purpose and return type but misses behavioral context like error handling or permissions. For a simple read operation, it's minimally adequate but lacks depth to fully guide an 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?
The input schema has 100% description coverage, with the parameter 'pattern' well-documented as a glob pattern (e.g., '*.jpg'). The description adds minimal value beyond the schema by reiterating the glob pattern matching, but doesn't provide additional semantics like examples of complex patterns or constraints. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'names of media files matching the glob pattern', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like media_retrieveMediaFile or media_storeMediaFile, which handle different operations on media files.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools like media_retrieveMediaFile (which retrieves file content) or media_deleteMediaFile (which deletes files), leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it states the tool creates a model and returns the created object, it lacks critical details: whether this requires specific permissions, if it's idempotent, what happens on duplicate model names, error conditions, or rate limits. For a creation tool with no annotation coverage, this is insufficient.
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 extremely concise—two brief sentences that state the action and the return value without any fluff. It's front-loaded with the primary purpose, making it efficient for quick comprehension. Every word earns its place.
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?
Given the complexity (a creation tool with 6 parameters, no annotations, and no output schema), the description is minimally adequate but has clear gaps. It covers the basic purpose and return value, but lacks usage guidelines, behavioral details, and output specifics. Without an output schema, the description should ideally hint at the structure of the 'created model object,' but it doesn't.
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 schema fully documents all 6 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters like how inOrderFields relates to cardTemplates). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates a new model') and specifies the resource ('model (note type)'), which distinguishes it from other creation tools like deck_createDeck or note_addNote. However, it doesn't explicitly differentiate from all sibling tools, such as model_updateModelStyling or model_updateModelTemplates, which also modify models but in different ways.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a model must not already exist), when to use model_updateModelStyling instead, or any constraints on usage. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool 'Gets' CSS styling and returns an object with a 'css' field, which implies a read-only operation. However, it lacks details on permissions, error handling (e.g., if the model doesn't exist), rate limits, or whether the CSS is editable. For a tool with no annotation coverage, this leaves significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two clear sentences: one stating the tool's purpose and another specifying the return value. There is no wasted language, and every sentence adds value by explaining what the tool does and what it returns.
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?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is moderately complete. It covers the basic purpose and return format but lacks details on behavioral aspects like error handling or usage context. Without annotations or an output schema, more guidance would improve completeness, but it's adequate for a simple retrieval tool.
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 has 100% description coverage, with the parameter 'modelName' documented as 'The name of the model.' The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score is 3, as the schema already provides adequate parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gets the CSS styling for the provided model name.' It specifies the verb ('Gets') and resource ('CSS styling'), and distinguishes it from siblings like model_updateModelStyling (which modifies styling) and model_findModelsByName (which searches models). However, it doesn't explicitly contrast with all siblings, such as model_modelTemplates, which might relate to styling but isn't directly addressed.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing model), exclusions, or comparisons to siblings like model_modelTemplates or model_updateModelStyling. The context is implied (retrieving styling for a model), but explicit usage instructions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 indicates a read operation ('Returns'), but fails to describe potential side effects, error conditions, authentication needs, or rate limits. This leaves significant gaps in understanding how the tool behaves in practice, especially for a tool that might involve data retrieval from a model.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness.
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?
For a tool with one parameter (fully documented in the schema) and no output schema, the description provides a basic understanding of what the tool does. However, it lacks details on the return format (e.g., structure of the 'object' or 'template content'), error handling, or integration with sibling tools, making it minimally adequate but incomplete for informed use.
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 has 100% description coverage, with 'modelName' clearly documented as 'The name of the model.' The description adds no additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and the resource ('template content for each card of the specified model'), making the purpose understandable. However, it does not explicitly differentiate this tool from its sibling 'model_updateModelTemplates', which appears to be a related write operation, leaving some ambiguity about when to choose one over the other.
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?
The description provides no guidance on when to use this tool versus alternatives, such as 'model_modelNamesAndIds' for listing models or 'model_updateModelTemplates' for modifying templates. It lacks context about prerequisites, typical use cases, or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the return type ('list of tags') but lacks critical details: whether it requires specific permissions, how it handles invalid note IDs (e.g., errors vs. empty lists), if there are rate limits, or what format the tags are in (e.g., strings, objects). For a read operation with zero annotation coverage, this is insufficient.
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 extremely concise—two short sentences that directly state the action and output without any fluff. It's front-loaded with the core purpose ('Gets the tags for a specific note ID'), and the second sentence adds necessary return information. Every word earns its place.
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?
Given the tool's low complexity (single parameter, read-only operation) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should ideally clarify behavioral aspects like error handling or tag format. It covers the basics but leaves gaps that could hinder effective use by an AI 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 description coverage is 100%, with the single parameter 'note' clearly documented as 'The ID of the note.' The description adds no additional parameter semantics beyond what the schema provides (e.g., no examples of valid note IDs, no constraints on ID format). This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Gets') and resource ('tags for a specific note ID'), making the purpose unambiguous. It distinguishes from siblings like note_addTags and note_removeTags by focusing on retrieval rather than modification. However, it doesn't explicitly differentiate from note_notesInfo which might also provide tag information, preventing a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like note_notesInfo (which might return tags along with other note details) or note_findNotes (which could filter by tags). It simply states what the tool does without context about prerequisites, timing, or trade-offs with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions that it returns a list of deck names, which is helpful, but fails to address potential behaviors like error handling, rate limits, authentication requirements, or whether the list is sorted or paginated. This leaves significant gaps in understanding how the tool operates.
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 two concise sentences that directly state the action and the return value without any fluff. It is front-loaded with the core purpose and efficiently communicates the essential information, making it easy for an agent to parse quickly.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and return type, but lacks details on authentication, error cases, or differentiation from siblings, which could be important for an agent to use it correctly in a broader context.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any, earning a baseline score of 4 for not introducing confusion or redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'gets' and resource 'complete list of deck names for the current user', making the purpose specific and understandable. However, it doesn't explicitly differentiate from its sibling 'deck_deckNamesAndIds', which likely returns names with IDs, leaving some ambiguity about when to choose one over the other.
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?
The description provides no guidance on when to use this tool versus alternatives like 'deck_deckNamesAndIds' or other deck-related tools. It lacks context about prerequisites, such as whether the user needs to be authenticated or if there are any limitations, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the return format but omits critical details like whether this is a read-only operation, if it requires specific permissions, how it handles invalid card IDs, or any rate limits. For a tool with zero annotation coverage, this leaves significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: it states the core purpose in the first clause and details the output format in the second. Every sentence earns its place with zero wasted words, making it highly efficient for agent comprehension.
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?
Given the tool's low complexity (single parameter, no nested objects) and 100% schema coverage, the description is adequate but incomplete. It lacks output schema, so the description must explain return values—which it does partially by specifying the list structure but not full behavioral context like error handling or permissions needed.
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 schema already fully documents the 'cards' parameter. The description adds no additional parameter semantics beyond what's in the schema (e.g., format details, constraints, or examples), meeting the baseline for high schema coverage but not providing extra value.
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 clearly states the specific action ('Returns modification time') and resource ('for each card ID provided'), distinguishing it from sibling tools like card_cardsInfo or card_findCards that return different card metadata. It precisely defines what the tool does without ambiguity.
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?
The description provides no guidance on when to use this tool versus alternatives like card_cardsInfo (which might include modTime among other fields) or card_findCards. It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value ('Returns list of booleans indicating success for each key') and hints at risk ('Use with caution'), but lacks details on permissions, rate limits, error handling, or what constitutes 'success' (e.g., validation rules). The warning about caution is vague without specifics.
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 two sentences, front-loaded with the core action and risk warning, followed by return value information. Every sentence adds value without redundancy, making it efficient and well-structured.
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?
Given no annotations and no output schema, the description partially compensates by explaining the return format. However, for a mutation tool with 4 parameters and potential risk ('Use with caution'), it lacks details on error conditions, side effects, or examples of safe usage, leaving gaps in completeness.
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 schema already documents all parameters well. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify the relationship between 'keys' and 'newValues' or provide examples beyond 'flags', 'odue'). Baseline 3 is appropriate as the schema handles most of the documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Sets') and resource ('specific values of a single card'), making the purpose understandable. However, it doesn't explicitly differentiate this from similar sibling tools like 'note_updateNote' or 'card_unsuspend', which could involve modifying card properties in different ways.
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?
The description includes 'Use with caution', which provides some guidance about risk, but it doesn't specify when to use this tool versus alternatives (e.g., 'note_updateNote' for note-level changes or 'card_suspend' for suspension). No explicit when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the return type ('array of note IDs') without detailing behavioral aspects like error handling, rate limits, permissions needed, or whether the search is case-sensitive. It mentions the query example but doesn't explain search limitations or result formatting.
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 a single, efficient sentence that front-loads the core functionality ('Returns an array of note IDs') and includes a practical example. There is no wasted verbiage or redundant information.
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?
For a single-parameter read operation with no output schema, the description is minimally adequate but lacks completeness. It doesn't explain the return format (e.g., array structure), error cases, or how results relate to other tools like 'note_notesInfo', leaving gaps for an AI agent to infer behavior.
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 schema already documents the single 'query' parameter with an example. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('array of note IDs'), specifying it's for an Anki search query. It distinguishes from sibling tools like 'note_notesInfo' (which returns full note info) by focusing on IDs only, but doesn't explicitly contrast with 'card_findCards' (which finds cards rather than notes).
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 implies usage for searching notes via Anki queries, but provides no explicit guidance on when to use this tool versus alternatives like 'card_findCards' or 'note_notesInfo'. It mentions the query format example but lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the return value (ID or null) but lacks details on permissions, error handling, rate limits, or side effects. For a creation tool with zero annotation coverage, this is a significant gap in transparency.
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-loaded with the core purpose in the first sentence and adds return value information in the second. Both sentences earn their place by providing essential details without redundancy, making it appropriately sized and efficient.
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?
Given the tool's complexity (creation operation with nested objects) and lack of annotations and output schema, the description is moderately complete. It covers purpose and return value but misses behavioral aspects like error conditions or side effects, which are important for a mutation tool with no structured safety hints.
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 schema already documents the single 'note' parameter and its structure. The description adds minimal value by listing components like 'deck, model, fields, and tags', but does not provide additional syntax or format details beyond what the schema specifies. Baseline 3 is appropriate when the schema handles most documentation.
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 clearly states the specific action ('Creates a new note') and the resources involved ('deck, model, fields, and tags'), distinguishing it from sibling tools like note_updateNote or note_addNotes. It precisely defines the tool's function without being vague or tautological.
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 implies usage for creating notes with specific components but does not explicitly state when to use this tool versus alternatives like note_addNotes (plural) or note_updateNote. No exclusions or prerequisites are mentioned, leaving usage context somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the return value (true/false) but lacks details on error handling, permissions required, rate limits, or what happens with invalid card IDs. For a read operation with zero annotation coverage, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, the second specifies the return value. It is front-loaded and appropriately sized for a simple lookup tool.
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?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and return value but lacks behavioral context like error cases or performance characteristics, which would be helpful for an agent.
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 100%, so the schema already documents the single parameter 'card' as an integer ID. The description adds no additional parameter semantics beyond what the schema provides, but with only one parameter and high coverage, the baseline is appropriately high.
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 clearly states the specific action ('Checks if a single card is suspended') and resource ('by its ID'), distinguishing it from siblings like card_suspend and card_unsuspend. It precisely defines the tool's function without being tautological.
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 implies usage for checking suspension status of a single card by ID, but does not explicitly state when to use this versus alternatives like card_areSuspended (which might handle multiple cards) or other card-related tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool can create decks if they don't exist, which is valuable behavioral context. However, it doesn't mention permissions needed, whether the operation is reversible, what happens if card IDs are invalid, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the core functionality with zero waste. Front-loaded with the primary action ('Moves cards'), followed by key behavioral detail ('creating the deck if it doesn't exist yet'). Every word earns its place.
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?
Given 2 parameters with full schema coverage and no output schema, the description adequately explains what the tool does. However, as a mutation tool with no annotations, it should ideally mention more about behavioral aspects like error conditions or side effects. The deck creation detail helps, but doesn't fully compensate for the lack of structured safety/behavioral information.
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 100%, so the schema already documents both parameters well. The description adds context about deck creation as a side effect of the 'deck' parameter, which provides additional semantic meaning beyond the schema's technical documentation. With 2 parameters and high schema coverage, this earns above baseline.
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 clearly states the specific action ('Moves cards'), identifies the resource ('cards with the given IDs'), and specifies the destination ('to a different deck'). It also distinguishes from siblings like 'deck_createDeck' by mentioning deck creation as a side effect rather than the primary purpose.
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 implies usage when needing to relocate cards between decks, but doesn't explicitly state when to use this versus alternatives like 'deck_createDeck' for deck-only creation or 'card_setSpecificValueOfCard' for other card modifications. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return format (array of booleans/null) and behavior for non-existent cards, which is useful. However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality and includes essential details (return type, handling of non-existent cards). There is no wasted verbiage, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the basic purpose and return format adequately. However, for a tool with potential complexity (e.g., batch processing, error cases), it lacks completeness in areas like authentication needs or response structure details.
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%, with the parameter 'cards' documented as 'A list of card IDs.' The description adds minimal value by implying the parameter is used to check suspension, but doesn't provide additional semantics like ID format or constraints beyond 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 clearly states the specific action ('Returns an array indicating whether each given card is suspended') and resource ('card'), distinguishing it from siblings like card_suspended (which likely checks suspension status differently) and card_suspend/unsuspend (which modify suspension). It explicitly handles non-existent cards with null values, adding precision.
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 implies usage for checking suspension status of multiple cards by IDs, with no explicit alternatives or exclusions. It doesn't specify when to use this over card_suspended or other siblings, but the context is clear for batch status queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: it's a creation operation (implies mutation), specifies non-overwriting behavior, and mentions the return value (ID). It lacks details on permissions, error handling, or side effects, but covers essential behavior adequately for a simple 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 front-loaded with the core action ('Creates a new empty deck'), followed by important behavioral notes and return information in just two sentences. Every sentence adds value: the first states the purpose, the second clarifies constraints and outcomes, with zero waste 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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is reasonably complete: it covers purpose, behavior, and return value. However, it could be more thorough by addressing potential errors or prerequisites, slightly reducing completeness for a mutation tool without annotations.
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%, with the parameter 'deck' fully documented in the schema. The description does not add any additional meaning beyond the schema's details (e.g., no extra context on naming conventions or constraints), so it meets the baseline of 3 for high schema coverage without compensating value.
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 clearly states the verb ('creates') and resource ('new empty deck'), distinguishing it from siblings like deck_deleteDecks (deletion) or deck_changeDeck (modification). It specifies the outcome ('empty deck') and what it returns ('ID of the created deck'), making the purpose unambiguous and distinct.
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 implies usage by stating 'Will not overwrite an existing deck with the same name,' which suggests this tool is for initial creation, not updates. However, it does not explicitly name alternatives (e.g., deck_changeDeck for modifications) or provide broader context on when to use it versus other deck-related tools, leaving some guidance gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that the tool retrieves base64-encoded contents and returns false if the file is not found, which is useful behavioral context. However, it lacks details on permissions, rate limits, error handling beyond 'not found', or side effects (e.g., if this logs access). For a retrieval tool with no annotations, this is adequate but not comprehensive.
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 two sentences that are front-loaded with the core action and resource, followed by return value details. Every sentence earns its place by specifying retrieval, encoding, and error handling, with zero waste or redundancy, making it highly efficient and well-structured.
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 low complexity (single parameter, no output schema, no annotations), the description is mostly complete: it covers purpose, output format, and error case. However, it lacks details on behavioral aspects like permissions or side effects, which would be beneficial for a retrieval tool in a media context. It's sufficient but could be slightly enhanced for full completeness.
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 has 100% description coverage, with the parameter 'filename' documented as 'The name of the media file in Anki's collection.' The description adds no additional parameter semantics beyond what the schema provides, such as file format constraints or path details. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also doesn't need to.
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 clearly states the verb 'retrieves' and the resource 'base64-encoded contents of the specified media file', specifying both the action and the exact output format. It distinguishes from sibling tools like media_getMediaFilesNames (which lists files) and media_storeMediaFile (which uploads files), making the purpose specific and differentiated.
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 implies usage context by stating 'Returns the base64 string or false if not found', suggesting it's for fetching file contents and handling missing files. However, it does not explicitly state when to use this versus alternatives like media_getMediaFilesNames for listing files or media_storeMediaFile for uploading, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool can accept multiple input types (data, path, url), returns either a filename or false on error, and operates on Anki's media folder. However, it doesn't mention permissions needed, rate limits, side effects beyond storage, or what happens with duplicate filenames beyond the deleteExisting parameter.
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 perfectly concise with two sentences that each earn their place: the first states the purpose and input options, the second states the return behavior. There's zero wasted language, and it's front-loaded with the core functionality.
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 moderate complexity (5 parameters, mutation operation), no annotations, and no output schema, the description does a reasonably complete job. It covers the core operation, input alternatives, and return values. However, it could better address error conditions, permissions, or interaction with sibling tools like media_deleteMediaFile for a more complete picture.
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 schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema by mentioning the three alternative input sources (data, path, url) but doesn't provide additional syntax, format details, or constraints beyond what's in the parameter descriptions. This meets the baseline for high 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 clearly states the specific action ('Stores a media file'), target location ('in Anki's media folder'), and distinguishes from siblings like media_deleteMediaFile and media_retrieveMediaFile by focusing on storage rather than deletion or retrieval. It uses precise verbs and specifies the resource being manipulated.
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 provides clear context for when to use this tool ('Provide one of 'data', 'path', or 'url'') which helps differentiate it from alternatives, but it doesn't explicitly state when NOT to use it or name specific sibling alternatives. The guidance is helpful but not exhaustive about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It clearly indicates this is a creation/write operation and describes the return behavior (list of IDs with null for failures). However, it doesn't mention authentication requirements, rate limits, error handling specifics, or whether operations are atomic.
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 sentences with zero waste: the first states purpose and references sibling tool, the second describes return behavior. Every word serves a clear purpose, and the most critical information (what it does) 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 creation tool with no annotations and no output schema, the description adequately covers the core functionality and return format. However, it lacks details about error conditions, partial success handling, or performance characteristics that would be helpful for a batch operation.
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 schema already documents the single 'notes' parameter. The description adds value by referencing 'addNote' for note structure details, but doesn't provide additional semantic context beyond what's implied by the schema's array type.
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 clearly states the specific action ('Creates multiple notes'), identifies the resource ('notes'), and distinguishes from its sibling 'note_addNote' by referencing it for structural details. This provides precise differentiation within the tool family.
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 explicitly references 'addNote' for note structure, providing clear guidance on when to use this tool versus its sibling for single-note creation. However, it doesn't specify when to choose this batch tool over multiple calls to 'addNote' or mention any prerequisites for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the operation is a 'get' (read-only) and describes the return format, but doesn't mention potential limitations like pagination, rate limits, permissions needed, or what happens with empty/no decks. It provides basic behavioral context but lacks depth.
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 sentences with zero waste: first states purpose, second specifies return format. Front-loaded with the core action, no redundant information, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no annotations and no output schema, the description covers purpose and return format adequately. However, it lacks details on error cases, empty responses, or performance characteristics that would help an agent use it robustly. It's minimally complete but has gaps.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters, and it appropriately focuses on the tool's purpose and output instead.
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 clearly states the verb ('Gets'), resource ('complete list of deck names and their respective IDs'), and output format ('dictionary mapping deck names to their IDs'). It distinguishes from sibling 'deck_deckNames' by specifying it returns both names AND IDs, not just names.
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 implies usage context (when you need both deck names and IDs), but doesn't explicitly state when NOT to use it or name alternatives. It differentiates from 'deck_deckNames' by mentioning IDs, providing some guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the return type ('dictionary mapping model names to IDs'), which is useful behavioral context. However, it does not mention potential limitations like rate limits, permissions needed, or whether the list is cached, leaving some gaps in transparency for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and follow with return details. Every word adds value without redundancy, making it efficient and easy to parse for an AI agent.
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 (0 parameters, no output schema, no annotations), the description is mostly complete: it states the purpose and return format. However, it could improve by mentioning any prerequisites or behavioral traits (e.g., if it requires specific permissions), but for a straightforward read operation, it is largely adequate.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and output, which aligns with the baseline expectation for parameterless tools.
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 clearly states the tool's purpose with a specific verb ('Gets') and resource ('complete list of model (note type) names and their IDs'), and distinguishes it from siblings like 'model_findModelsByName' (which searches) and 'model_modelFieldNames' (which focuses on fields). It precisely defines what the tool does without ambiguity.
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 implies usage for retrieving all model names and IDs, which is clear in context, but does not explicitly state when to use this tool versus alternatives like 'model_findModelsByName' (for searching) or 'deck_deckNamesAndIds' (for decks). It provides adequate context but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![anki-mcp MCP server](https://glama.ai/mcp/servers/ujisati/anki-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ujisati/anki-mcp)

Score Badge

Copy to your README.md:

[![anki-mcp MCP server](https://glama.ai/mcp/servers/ujisati/anki-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ujisati/anki-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ujisati/anki-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server