Learn vocabulary from daily life with flashcards, examples, pronunciation and shareable study links.
Scored across 3 tools
The two deck-creation tools (create_flashcard_deck vs create_website_deck) overlap in purpose, but their descriptions explicitly distinguish in-conversation UI decks from persistent website-sharing decks. speak_text is clearly separate for widget-triggered audio. Minor risk remains that an agent could confuse the two create tools.
All tool names use consistent snake_case and follow a predictable verb_noun pattern: create_flashcard_deck, create_website_deck, speak_text. The naming is readable and predictable throughout.
Three tools is a narrow but reasonable surface for a focused flashcard server: create a study deck, persist/share it, and speak card text. It is slightly thin but each tool earns its place without bloat.
The server covers deck creation and sharing but lacks any tool to list, retrieve, update, or delete existing decks, leaving significant lifecycle gaps. Agents cannot manage decks after creation, limiting real workflows.
Use this when the user asks to learn, study, memorize, review, practice, or create flashcards about any topic. Generate the complete deck in this call and open it in the interactive flashcard UI. Act immediately using the existing conversation and source material; infer language and backLanguage yourself. Never ask the user for language codes, tool arguments, or confirmation of an already requested deck. For a request for 50 cards, submit all 50 completed cards in one call. Keep the response brief and let the study UI show the deck. Examples include 'I want to learn about X', 'teach me X with flashcards', and 'Create an HSK3 vocabulary deck about restaurants'. Do not call a separate add-card tool. Do NOT use when the user asks for a direct explanation without study intent, asks to delete or modify an existing deck, or requests an in-conversation quiz without creating a deck.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes | The complete generated deck. Include exactly the number of cards the user requested, with every required language-learning field completed; never submit a partial array or placeholders. | |
| title | Yes | A concise, descriptive title for the generated deck. | |
| language | No | ISO 639-1 code for the language spoken on the front side (e.g. 'zh' Chinese, 'ja' Japanese, 'vi' Vietnamese). Used for the correct audio voice and saved-deck language. Always infer and set it from the user's target language, never from their current app preference. | |
| backLanguage | No | Language of the translations on the back. Set from the user’s known language; never assume English. Always set for language-learning decks. Used for reverse-card audio. |
| Name | Required | Description |
|---|---|---|
| cards | Yes | |
| title | Yes | |
| language | No | |
| cardCount | Yes | |
| backLanguage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the call creates a complete deck and opens it in an interactive flashcard UI, and the schema references a 'saved-deck' language, yet the annotations declare readOnlyHint=true (no environment modification) and idempotentHint=true for what is a creation operation. This is a direct conflict between the described write/UI side effect and the declared read-only semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the trigger condition and the 'do it in one call' constraint before the examples and exclusions. Slightly redundant, since the opening verb list (learn, study, memorize, review, practice) is restated by the quoted example utterances, but overall dense with little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and the input schema is fully documented, so return values need no explanation; the description still covers triggers, cardinality expectations, and language inference. What it omits is whether the created deck is persisted/saved or ephemeral, which is exactly the point where the readOnlyHint annotation is misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds real semantic guidance beyond the schema: infer language and backLanguage from the target language rather than app preference, never ask for language codes, and submit all N requested cards as one complete array rather than partial or placeholder entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (generate/create a complete deck) and resource (flashcard deck) plus the trigger intent (learn, study, memorize, review). It is immediately understandable, but it never names or contrasts with the sibling create_website_deck, so the agent must infer the split between the two deck-creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use triggers with sample user utterances, explicit when-NOT-to-use cases (no-study-intent explanation, delete/modify existing deck, in-conversation quiz without a deck), and an explicit exclusion of a separate add-card tool. It also removes decision friction by instructing the agent to act immediately without asking for confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user explicitly asks to save or share a deck on the website, or chooses Learn on website in the study widget. It sends the supplied deck to Fulin Labs and creates a persistent shareable deck link. Anyone with the link can read the deck. Do not call merely to preview or study a deck. Repeating the call may create another deck.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes | The cards the user explicitly chose to save on Fulin Labs. | |
| title | Yes | The title of the deck the user chose to save. | |
| language | No | Optional language code for the deck's front side. |
| Name | Required | Description |
|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds meaningful context beyond those annotations: the deck is sent to Fulin Labs, the resulting link is publicly readable by anyone with it, and repeating the call may create another deck.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loads the usage condition, and every sentence adds useful information about when to call, what happens, and what to avoid. There is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema, and annotations, the description is complete enough for correct invocation. It covers usage conditions, public-link behavior, and duplicate-call risk, leaving no critical gap for an agent deciding whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the title, cards, and language parameters in detail. The description does not add parameter-level syntax or constraints beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: it sends a supplied deck to Fulin Labs and creates a persistent shareable deck link. It distinguishes this from previewing or studying a deck, but it does not explicitly differentiate from the sibling create_flashcard_deck tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear triggering conditions: the user explicitly asks to save/share on the website, or chooses Learn on website in the study widget. It also gives a clear when-not condition: do not call merely to preview or study a deck. It does not name an alternative sibling tool for non-website deck creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the flashcard widget requests speech audio for the current card.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to speak. | |
| language | Yes | Language of the text being spoken. Always specify the current side’s language; never default to the other side or app preferences. |
| Name | Required | Description |
|---|---|---|
| contentType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive behavior with closed-world scope. The description adds the flashcard-widget usage context, but it does not disclose whether audio is played directly or returned, nor any other runtime behavior beyond what annotations and the output schema cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the usage condition with no redundant or filler content. It is appropriately sized for this simple, well-specified tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, annotations, complete parameter schema, enum constraint, and output schema together give an agent enough to call the tool correctly. The only gap is that the description does not explicitly state the audio output behavior, but the title and output schema compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the input schema, including the language enum and the instruction to use the current side's language. The description adds no further parameter semantics, which is a baseline 3 given the strong schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the triggering context - flashcard widget requests speech audio for the current card - which clearly implies the tool produces speech audio for that card. It does not explicitly say 'convert text to speech' or describe the output, but the purpose is readily inferable and not a mere restatement of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear when-to-use condition: when the flashcard widget requests speech audio for the current card. It does not mention alternatives or when not to use it, but no sibling tool is a plausible substitute, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_flashcard_deckcreate_website_deckspeak_textBuild and enrich your Lingard vocabulary: topic collections, flashcards, translations, examples.
Flashcard decks with pictures and card designs for a free vocabulary site in 60 languages.
Language flashcards in your AI assistant: build decks, edit cards and review what's due in the chat.
Make Anki, Quizlet, Mochi and Brainscape decks and review your vocabulary from the chat.
Add one secure layer between your agents and this server.
