Skip to main content
Glama
Sign In

NextLang

by co.nextlang
OverviewDiscussionsAdmin

Generate a flashcard deck

generate_deck

Generates a new flashcard deck with NextLang's own generator and saves it to the user's account. Costs 1 credit: unless the user explicitly asked for a new deck, confirm first. A tentative request ('maybe make me a deck', 'could we do one about...') is not an explicit one: confirm first. Cards are built from 'prompt' (a topic, a situation or a short text of up to 500 characters); the front of each card is in learningLanguage. It makes basic front/back cards only: cloze (fill-in-the-blank) decks are made on the NextLang website, so do not promise cloze cards from this tool. Returns the cards, a link to the deck on NextLang (the user downloads and studies it there) and the remaining credits. For Quizlet and Brainscape, send the user to that link to import: its Copy button keeps the exact separators, which copying from a chat often turns into spaces. Offer the cards as text only as a fallback. Do not call get_credits first: when the balance is too low this tool says so and returns a link explaining credits. If this call fails or times out, call list_decks before trying again: the deck may already exist, and generating again spends another credit.

Input Schema

NameRequiredDescriptionDefault
countYesNumber of cards (free accounts: up to 15)
levelNoCEFR level of the words. Pass it only when the user named a level; otherwise leave it out and b1 is used
promptYesA topic, a situation or a short text to build the deck from
platformYesFlashcard app the deck is for
learningLanguageYesLanguage being learned; the front of each card
translationLanguageYesLanguage of the translations

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / count / minimum
      Previous value: -1New value: +5
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations mark it non-readonly, non-idempotent and non-destructive, and the description goes well beyond that: it discloses the 1-credit cost, the confirmation requirement, that a repeat generation spends another credit, that the deck may already exist after a timeout, and exactly what is returned (cards, deck link, remaining credits).

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?

Long, but front-loaded with purpose then cost, and nearly every sentence carries a distinct routing or safety instruction. A few clauses (the Copy-button detail, the text fallback) could be tightened without losing the definition's core.

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

Completeness5/5

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

Despite no output schema, the description enumerates return values, covers the credit-failure path, the timeout-recovery path, and the alternative import flows, leaving nothing an agent needs in order to call 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 coverage is 100%, so all six parameters are already documented, including the b1 default for level and the 500-character prompt cap. The description restates the prompt's nature and that learningLanguage drives the card front, adding only marginal meaning 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 opening sentence names a specific verb and resource ('Generates a new flashcard deck'), states the generator used and that it is persisted to the account, which cleanly separates it from save_deck, expand_deck and get_deck.

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?

Explicitly routes the agent: confirm before spending a credit unless the request was explicit, including a definition of what counts as tentative; do not call get_credits first; on failure call list_decks before retrying. It also names where the excluded capability (cloze) lives and how Quizlet/Brainscape users should proceed.

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

All NextLang toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources