Mochi MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as create_card_preview vs. apply_create_card for previewing and confirming card creation, or get_card vs. get_cards for single vs. bulk retrieval. However, there is some overlap between update_card_preview and update_card_fields_preview, both used for previewing card updates, which could cause minor confusion for agents.
Naming Consistency5/5
Tool names follow a consistent snake_case pattern with clear verb_noun structures, such as create_card_preview, apply_create_card, and list_decks. The naming is predictable and readable throughout the set, with no deviations or mixed conventions.
Tool Count4/5
With 20 tools, the count is slightly high but reasonable for a flashcard management server, covering operations like creation, updates, deletion, searching, and deck management. It includes necessary preview and confirmation steps, though it could be streamlined without losing functionality.
Completeness5/5
The tool set provides comprehensive coverage for flashcard management, including full CRUD operations for cards and decks (e.g., create, get, update, delete), batch processing, tagging, searching, and pagination. There are no obvious gaps, and agents can handle typical workflows without dead ends.
Average 3.4/5 across 20 of 20 tools scored. Lowest: 2.3/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 the full burden of behavioral disclosure. 'Create a new deck' implies a write operation but doesn't specify permissions needed, whether it's idempotent, what happens on duplicate names, or what the response contains. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
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 at three words, with zero wasted language. It's front-loaded with the core action and resource. While under-specified, it's not verbose or poorly structured—every word earns its place by stating 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?
Given the complexity of a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'deck' is, how it relates to other entities (like cards), what happens after creation, or error conditions. For a tool that likely modifies system state, this leaves too many contextual gaps for effective agent 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 both parameters ('name' and 'parentId') clearly documented in the schema. The description adds no parameter-specific information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new deck' is a tautology that restates the tool name without adding meaningful context. It specifies the verb ('create') and resource ('deck'), but doesn't distinguish this from sibling tools like 'create_card_preview' or explain what a 'deck' represents in this system. The purpose is clear at a basic level but lacks differentiation from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 like 'create_card_preview', 'find_deck_by_name', and 'list_decks', there's no indication of when creation is appropriate versus searching or listing. No prerequisites, constraints, or comparative context 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?
No annotations are provided, so the description carries full burden. It indicates this is a mutation tool ('Execute card update'), but lacks details on permissions, side effects, error handling, or response format. The phrase 'after user confirms' hints at a workflow step, but doesn't clarify if this is destructive, irreversible, or has rate limits, making behavioral traits insufficiently disclosed.
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: 'Execute card update after user confirms'. It's front-loaded with the core action and includes a key constraint, making it appropriately sized and easy to parse.
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 with no annotations and no output schema), the description is incomplete. It lacks details on what 'card update' involves, the outcome, error conditions, or how it fits with siblings like 'update_card_preview'. Without annotations or output schema, more context is needed for effective agent 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 parameters 'token' and 'confirmation' fully documented in the schema. The description adds no additional meaning beyond implying a sequence ('after user confirms'), but doesn't explain parameter relationships or usage context. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 'Execute card update after user confirms' states the action (execute) and resource (card update), but is vague about what 'card update' entails compared to siblings like 'apply_update_cards_batch' or 'update_card_fields_preview'. It doesn't specify if this applies to a single card or batch, or what aspects of a card are updated, leaving 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 mentions 'after user confirms', implying a prerequisite (user confirmation), but provides no explicit guidance on when to use this tool versus alternatives like 'apply_update_cards_batch' or 'update_card_preview'. There's no mention of scenarios, exclusions, or comparisons to sibling tools, leaving usage 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, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't indicate if this is a mutation (likely, given 'apply'), its effects (e.g., irreversible changes), permissions needed, error handling, or rate limits. This leaves critical gaps for a tool that appears to perform batch operations.
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 no wasted words. It's front-loaded with the core action and resource, making it easy to scan. Every word earns its place, achieving optimal 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 tool's complexity (batch updates, likely mutations) and lack of annotations or output schema, the description is incomplete. It doesn't cover what 'apply' entails, the batch's scope, success/failure behavior, or return values. For a tool with significant potential impact, this minimal description 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, detailing both parameters ('token' from preview and 'confirmation' string). The description adds no additional meaning beyond the schema, such as explaining the batch content or process. Baseline 3 is appropriate since the schema fully documents parameters.
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 'Apply a batch of card updates' clearly states the action (apply) and resource (batch of card updates), but it's vague about what 'apply' entails (e.g., commit, execute, process) and doesn't distinguish it from siblings like 'apply_update_card' (single card) or 'update_cards_batch_preview' (preview). It's adequate but lacks specificity.
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., needing a token from 'update_cards_batch_preview'), exclusions, or comparisons to siblings like 'apply_update_card' or 'update_cards_batch_preview'. The description alone offers no 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('Get content'), but doesn't describe any behavioral traits like whether it's read-only, performance characteristics, error handling, or what happens with invalid IDs. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 at just 5 words, front-loading the essential information ('Get content of multiple cards') with a clarifying parenthetical ('bulk'). Every word earns its place with zero waste or redundancy.
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 read operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'content' includes, the format of returned data, pagination behavior, or error conditions. While the schema covers the single input parameter well, the overall context for using this tool effectively 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?
The schema description coverage is 100%, with the single parameter 'cardIds' well-documented in the schema as 'List of Card IDs to retrieve'. The description adds no additional parameter semantics beyond implying bulk operation through 'multiple cards', which aligns with the array parameter type. 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 ('Get') and resource ('content of multiple cards') with the qualifier 'bulk', making the purpose evident. It distinguishes from the sibling 'get_card' by specifying multiple cards, but doesn't explicitly differentiate from other list/search tools like 'list_cards_page' or 'search_cards' beyond the bulk retrieval aspect.
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 when to choose this bulk retrieval over individual 'get_card' calls, or when to prefer 'list_cards_page' or 'search_cards' for different retrieval needs. The agent must infer usage from the tool 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves deck details and a card list, implying a read-only operation, but doesn't disclose critical traits like whether it's safe (non-destructive), what authentication is needed, rate limits, or the format of returned data. This is inadequate for a 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 extremely concise with a single sentence, 'Get deck details and list of cards', which is front-loaded and wastes no words. Every part of the sentence directly contributes to understanding the tool's purpose, making it efficiently structured.
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 retrieving deck details and a card list, with no annotations and no output schema, the description is incomplete. It doesn't explain what 'deck details' include, how the card list is formatted, or any behavioral aspects like pagination or error handling. This leaves significant gaps for the agent to infer.
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 single parameter 'deckId' clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as explaining the deck ID format or 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 verb 'Get' and the resource 'deck details and list of cards', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_card' (which retrieves a single card) or 'find_deck_by_name' (which finds decks by name rather than ID), 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. It doesn't mention when to prefer 'get_deck' over 'get_card' for card details or 'list_decks' for deck listings, nor does it specify prerequisites like needing a deck ID. This leaves 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 full burden. It mentions 'preview' which suggests non-destructive read-only behavior, but doesn't clarify if this is a dry-run simulation, what the preview output looks like, whether it validates inputs, or if there are rate limits. For a batch operation tool 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?
Extremely concise single sentence with zero waste - 'Preview updates for multiple cards at once.' Front-loaded with the core purpose. Every word earns its place.
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 batch preview tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the preview shows, how results are returned, error handling for invalid updates, or limitations on batch size. Given the complexity of batch operations and lack of structured metadata, more context 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%, with the 'updates' parameter fully documented in the schema. The description adds no additional parameter semantics beyond implying batch processing of multiple cards. 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 ('Preview updates') and resource ('multiple cards'), distinguishing it from single-card preview tools like 'update_card_preview'. However, it doesn't specify what kind of updates (content/tags) or how it differs from 'apply_update_cards_batch' which likely applies rather than previews.
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 on when to use this tool versus alternatives like 'update_card_preview' (single card) or 'apply_update_cards_batch' (actual application). The description implies batch operations but doesn't specify prerequisites, limitations, or comparative contexts 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 retrieving 'full content' but doesn't specify whether this is a read-only operation, if it requires authentication, potential rate limits, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 any wasted words. It is appropriately sized and front-loaded, making it easy to grasp immediately.
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 minimally adequate. It explains what the tool does but lacks details on behavior, usage context, or output format, which would be needed for a more complete understanding in a server with many 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, with 'cardId' clearly documented as 'Card ID to retrieve'. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline score 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 ('Get') and resource ('full content of a single card'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_cards' or 'search_cards', which might retrieve multiple cards or filtered results, so it doesn't reach the highest 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 such as 'get_cards' (for multiple cards) or 'search_cards' (for filtered searches). It simply states what the tool does without context about its appropriate use cases 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 states the action ('List all') but doesn't describe return format, pagination, permissions needed, or error conditions. For a list operation 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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple list operation and front-loaded with the essential 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?
Given the tool's low complexity (single optional parameter) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should ideally provide more context about what the list returns and any behavioral constraints, but the simplicity of the operation keeps it from being severely incomplete.
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 single parameter 'includeArchived' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where 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 ('List') and resource ('all Mochi flashcard decks'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'find_deck_by_name' or 'get_deck', which also retrieve deck information but with different scopes or filtering capabilities.
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 'find_deck_by_name' or 'get_deck'. It lacks any mention of prerequisites, context for use, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'preview' operation, implying it's non-destructive and read-only, but doesn't clarify if it requires specific permissions, how it handles partial field updates, or what the preview output looks like. For a tool with mutation-like parameters (question, answer, tags) but preview behavior, more context on safety and output format is needed.
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 and front-loaded with essential information in just two sentences. The first sentence covers the core purpose and parameters, while the second adds important behavioral context ('Reconstructs full markdown'). There is no wasted verbiage, and 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 complexity (previewing changes to multiple fields), lack of annotations, and no output schema, the description is moderately complete but has gaps. It clarifies the preview nature and specific fields, but doesn't explain the preview output format, error conditions, or how it differs from similar sibling tools. This leaves the agent with incomplete context for reliable invocation.
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 lists the specific fields (Question, Answer, Tags) that can be previewed, which adds meaning beyond the input schema's parameter names. However, with 100% schema description coverage, the schema already documents each parameter thoroughly (e.g., 'cardId' as 'Card ID to update'). The description doesn't provide additional syntax, format, or constraints, so it 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 tool's purpose: 'Preview changes to specific fields (Question, Answer, Tags). Reconstructs full markdown.' It specifies the verb ('Preview changes'), resource ('specific fields'), and scope ('Reconstructs full markdown'), making it clear this is a preview operation rather than an actual update. However, it doesn't explicitly distinguish itself from sibling tools like 'update_card_preview' or 'update_cards_batch_preview', which appear to serve similar preview functions.
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 a cardId), exclusions, or compare it to siblings like 'update_card_preview' or 'apply_update_card'. The agent must infer usage from the name and description alone, which is insufficient for optimal 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 mentions 'Execute card creation', implying a write operation, but doesn't disclose behavioral traits such as permissions needed, whether it's idempotent, error handling, or what happens on success/failure. This is a significant gap for a tool that likely 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the main action ('Execute card creation') and includes essential context ('after user confirms'). There is no wasted verbiage, 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.
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 card creation tool with no annotations and no output schema, the description is insufficient. It lacks details on what the tool returns, error conditions, or how it fits into the broader workflow with siblings like 'create_card_preview'. This leaves the agent with incomplete information for reliable invocation.
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 ('token' and 'confirmation') with clear descriptions. The description adds no additional meaning beyond what's in the schema, such as explaining the relationship between 'token' and 'create_card_preview' or the purpose of the confirmation step. 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 ('Execute card creation') and the condition ('after user confirms'), which is specific and actionable. However, it doesn't distinguish this tool from sibling tools like 'create_card_preview' or 'create_deck', leaving some ambiguity about its unique role in the workflow.
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 context ('after user confirms'), suggesting this is a follow-up step, but it doesn't explicitly state when to use this tool versus alternatives like 'create_card_preview' or 'create_deck'. No exclusions or prerequisites are mentioned, leaving the agent to infer the workflow.
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 adds some behavioral context by mentioning the return format ('rich results with deckId, createdAt, updatedAt') and flags ('scannedCount and truncated flags'), which helps understand output behavior. However, it doesn't cover critical aspects like rate limits, authentication needs, or error handling, leaving gaps for a search tool.
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 concise and front-loaded, stating the core functionality in the first sentence and adding output details in the second. Both sentences earn their place by providing essential information without redundancy. However, it could be slightly more structured by explicitly separating search inputs from output details for clarity.
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 of a search tool with 6 parameters and no output schema, the description is moderately complete. It covers the basic purpose and output format but lacks details on error cases, pagination, or how results are ordered. Without annotations, it should provide more behavioral context to fully guide an agent, 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?
The input schema has 100% description coverage, so parameters are well-documented in the schema itself. The description adds minimal value beyond the schema, as it only mentions search criteria ('content, tags, or date') without explaining parameter interactions or usage nuances. This meets the baseline for high schema coverage but doesn't enhance understanding significantly.
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: 'Search cards by content, tags, or date.' It specifies the resource (cards) and the search criteria, making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_cards_page' or 'get_cards', which might have overlapping functionality, so it doesn't reach the highest 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. With siblings like 'list_cards_page', 'get_cards', and 'find_deck_by_name', there's no indication of scenarios where 'search_cards' is preferred, such as for complex queries versus simple listing. This lack of comparative context leaves usage ambiguous.
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 lacks critical behavioral details. It mentions the preview nature and token output, but doesn't disclose whether this requires permissions, if it's idempotent, rate limits, or error conditions. For a mutation-related tool, 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, efficient sentence that front-loads the purpose and includes essential output information. Every word earns its place with zero wasted text, 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 provides basic purpose and output token information but lacks details on behavioral traits, error handling, or what the token represents. For a preview tool that likely involves validation, this is adequate but leaves clear 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 fully documents both parameters ('cardIds' and 'tagsToAdd'). The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score for high 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 ('Preview adding tags'), the target resource ('to one or more cards'), and distinguishes it from siblings by mentioning the output token for 'apply_tags_update'. It uses precise verbs and resources, avoiding tautology.
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 specifying it's a preview operation that returns a token for 'apply_tags_update', suggesting it should be used before applying changes. However, it doesn't explicitly state when not to use it or name alternatives like 'remove_tags_preview' for removal scenarios.
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 key behavioral traits: pagination mechanism ('explicit pagination') and use case ('iterating through large collections'). However, it lacks details on error handling, rate limits, authentication needs, or what happens if parameters are invalid. The description adds value but doesn't fully compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidance. Every sentence earns its place, and it's front-loaded with the core functionality. No wasted words or redundancy.
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 (pagination tool with 3 parameters), no annotations, and no output schema, the description is minimally adequate. It covers purpose and usage but lacks details on return values, error cases, or performance characteristics. It meets basic needs but leaves gaps that could hinder effective tool selection.
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 (deckId, bookmark, pageSize) with their types and descriptions. The description doesn't add any additional meaning beyond what the schema provides, such as explaining pagination flow or default behaviors. 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 tool's purpose: 'Fetch a single page of cards with explicit pagination.' It specifies the verb (fetch), resource (cards), and scope (single page with pagination). However, it doesn't explicitly differentiate from sibling tools like 'get_cards' or 'search_cards', which might offer different retrieval mechanisms.
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 on when to use this tool: 'Use for iterating through large collections.' This implies it's suitable for paginated access to large datasets. It doesn't explicitly state when not to use it or name alternatives, but the context is helpful for understanding its intended application.
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 mentions that this tool applies changes after user confirmation, implying a mutation operation, but it doesn't disclose behavioral traits like whether it's idempotent, what happens on failure, or if it requires specific permissions. The description adds some context but lacks depth 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 two sentences, front-loaded with the main purpose, and every word earns its place. It efficiently conveys the tool's function and usage without any 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 no annotations and no output schema, the description is moderately complete. It covers the purpose and prerequisites but lacks details on behavioral aspects like error handling or return values. For a mutation tool with two parameters, it's adequate but has clear gaps in transparency.
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 referencing the token's source ('from add_tags_preview or remove_tags_preview'), but it doesn't provide additional semantics beyond what the schema states. 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 action ('Apply tag changes') and the resource ('tags'), and it specifies the timing condition ('after user confirms'). However, it doesn't explicitly differentiate this tool from sibling tools like 'add_tags_preview' or 'remove_tags_preview' beyond mentioning their tokens as inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'after user confirms' and 'Use with token from add_tags_preview or remove_tags_preview.' It clearly indicates the prerequisite tools and the confirmation step, making it easy to distinguish from alternatives.
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 full burden and adds valuable behavioral context: it discloses the default soft-delete behavior, the requirement for typed confirmation, and implies irreversibility for permanent deletion via the parameter description. However, it does not cover rate limits, authentication needs, or error conditions.
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 action and default behavior, followed by a key requirement. Every sentence earns its place with no wasted words.
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 deletion tool with no annotations and no output schema, the description is reasonably complete: it covers the action, default behavior, and a key requirement. However, it lacks details on what 'soft-delete' entails (e.g., recovery options) and does not mention the response format or error handling.
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. The description adds no additional parameter semantics beyond what the schema provides (e.g., it does not explain the format of 'cardId' or the implications of 'permanent'). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a card'), and specifies the default behavior ('soft-delete by default'). This distinguishes it from siblings like 'delete_deck' (different resource) and 'get_card' (different action).
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 deleting a card, but does not explicitly state when to use this tool versus alternatives like 'delete_deck' or 'get_card' (for checking before deletion). It mentions a prerequisite ('Requires typed confirmation') but lacks explicit when-not-to-use guidance or named alternatives.
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, the description carries full burden and discloses critical behavioral traits: it's a destructive operation (implied by 'Delete'), requires explicit environment configuration, and includes a confirmation parameter for safety. However, it doesn't detail error cases or irreversible consequences.
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, front-loaded sentence with zero waste—every word adds value (action, resource, configuration requirement). It's appropriately sized for a simple destructive operation.
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 destructive tool with no annotations or output schema, the description covers purpose and prerequisites but lacks details on outcomes (e.g., what happens to associated cards), error handling, or confirmation rationale. It's minimally adequate given the complexity.
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 no additional parameter semantics beyond what the schema provides, meeting the baseline for high 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 action ('Delete') and resource ('a deck'), with specific differentiation from siblings like 'delete_card' by focusing on deck-level deletion. It's specific and unambiguous.
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 explicit context for when to use it ('disabled by default, requires MOCHI_ALLOW_DECK_DELETE=true'), but doesn't mention alternatives like 'delete_card' or when not to use it (e.g., 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 the full burden. It discloses the search behavior ('case-insensitive partial match'), which is useful, but lacks details on permissions, rate limits, pagination, or return format. For a read operation 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?
Two sentences with zero waste: the first states the purpose and behavior, the second provides usage guidance. It is front-loaded with essential information and 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 no annotations, no output schema, and a simple single-parameter input, the description covers purpose and usage well but lacks behavioral details like return format or error handling. It's complete enough for basic use but could be enhanced with more context on 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%, with the parameter 'query' documented as 'Name or partial name to search for'. The description adds context by reinforcing this as a search input but doesn't provide additional syntax or format details beyond what the schema already covers.
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 ('find') and resource ('decks by name'), specifies the matching behavior ('case-insensitive partial match'), and distinguishes it from sibling tools like 'list_decks' and 'get_deck' by focusing on name-based searching rather than listing all decks or retrieving by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('when you know the deck name but not its ID'), providing clear context for selection over alternatives like 'get_deck' (which requires ID) or 'list_decks' (which lists all decks without filtering).
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 of behavioral disclosure. It reveals this is a preview operation (not an actual mutation) and mentions the token return, which is valuable context. However, it doesn't disclose permissions needed, rate limits, error conditions, or what happens if tags don't exist on cards.
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 just two sentences that each serve a distinct purpose: the first states the tool's function, the second explains the return value and its purpose. There's zero wasted language or redundancy.
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 preview tool with 2 parameters and no annotations or output schema, the description provides the essential context about it being a preview operation and token return. However, it lacks information about what the preview actually shows, error handling, or limitations, leaving some gaps in understanding the tool's full 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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, maintaining the baseline score of 3 for adequate coverage through structured data alone.
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 ('Preview removing tags') and target resource ('from one or more cards'), distinguishing it from sibling tools like 'add_tags_preview' or 'apply_tags_update'. It explicitly identifies what the tool does in a precise verb+resource format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Preview removing tags') and provides a clear alternative ('Returns a token for apply_tags_update'), indicating this is a preview operation that should be followed by the apply tool. This gives explicit guidance on workflow sequencing.
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 of behavioral disclosure. It effectively describes key behavioral traits: this is a preview operation (not a final creation), it requires user confirmation before proceeding, and it has a specific workflow constraint (must not be chained automatically). However, it doesn't mention potential side effects like rate limits or authentication needs.
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 well-structured: two sentences that front-load the core purpose ('Preview a new card') followed by critical workflow instructions. Every sentence earns its place by providing essential guidance without any wasted words.
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 complexity (preview operation with workflow constraints), no annotations, and no output schema, the description is mostly complete. It clearly explains the purpose, usage guidelines, and behavioral workflow. However, it doesn't describe what the preview output looks like or any error conditions, leaving some gaps in 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?
Schema description coverage is 100%, so the schema already documents all three parameters (deckId, content, tags) with their descriptions. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage through structured data alone.
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 ('preview') and resource ('new card'), distinguishing it from sibling tools like 'apply_create_card' (which applies the creation) and 'create_deck' (which creates a different resource). It explicitly defines the action as a preview rather than a final creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it states when to use this tool (to preview a new card) and when not to (do NOT chain calls automatically), and specifies the required follow-up action (show preview to user and ask for confirmation before calling 'apply_create_card'). It clearly distinguishes this from its sibling 'apply_create_card'.
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 of behavioral disclosure. It effectively communicates that this is a non-destructive preview operation (implied by 'Preview changes' and the requirement to confirm before applying), and it establishes a specific workflow requirement (showing diff and waiting for confirmation). However, it doesn't mention rate limits, authentication needs, or what happens if the card doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core purpose in the first sentence, followed by critical workflow guidance. Every sentence earns its place by providing essential information about the tool's purpose and required usage pattern.
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 mutation-related tool with no annotations and no output schema, the description does well by clearly establishing the preview nature of the operation and the required confirmation workflow. However, it doesn't describe what the preview output looks like or what happens in error cases, leaving some 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 three parameters. The description doesn't add any additional parameter semantics beyond what's in the schema - it doesn't explain format expectations, constraints, or examples. The baseline of 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.
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 ('Preview changes') and resource ('to a card with diff'), distinguishing it from siblings like 'apply_update_card' which actually applies changes. It explicitly indicates this is a preview operation rather than an actual update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it states that after calling this tool, you MUST show the diff to the user and ask for confirmation before calling 'apply_update_card'. This creates a clear workflow distinction between preview and application tools.
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:

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

Score Badge

Copy to your README.md:

[![mochi-mcp MCP server](https://glama.ai/mcp/servers/NZ99/mochi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NZ99/mochi-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/NZ99/mochi-mcp'

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