Save vocabulary from any AI chat; see each word in every language you know; review it with FSRS.
Scored across 5 tools
The five tools cover distinct operations: reading languages, initial language setup, looking up a word, saving one word, and saving multiple words. The boundary between save_word and save_words is mostly clear from the descriptions, but a confusing mention of a 'save_languages' parameter in save_word slightly muddies the distinction.
All tool names use a consistent snake_case verb_noun pattern (get_languages, lookup_word, save_word, save_words, set_languages). The singular/plural distinction between save_word and save_words is intuitive and predictable.
Five tools is a well-scoped set for a vocabulary-capture connector, with each tool earning its place: setup, language retrieval, lookup, and single/batch saving. No obvious redundancy or missing tool bloat.
The surface covers account setup, language retrieval, lookup, and both single and batch saving, which handles the core capture workflow. However, there is no tool to delete or manage saved vocabulary (e.g., remove a word or list saved words), leaving minor gaps for full lifecycle management.
Returns the languages this Koboshi account is set to: the language meanings are written in, the language being learned, and any others the user has added. The same list arrives with the connect-time instructions and on the [account: ...] tag of every result, so this tool is for the case where that list was missing or has just been changed. The account setting is the only place these languages live; they are unrelated to the languages on the user's device or in this conversation. Takes no arguments and writes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description still adds real context: it discloses that this account setting is the sole source of these languages and that the tool 'takes no arguments and writes nothing,' which usefully bounds side effects. It stops short of describing return shape beyond the field list.
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 purpose, then the when-to-use condition, then the scoping caveat. Every sentence carries information the agent needs; nothing is padded or repeated from the annotations.
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?
For a no-argument, read-only tool with no output schema, the description supplies the returned fields, the reason to call it, and the boundary of what it covers. Nothing an agent needs in order to call it correctly is missing.
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?
Zero parameters, so the baseline is 4. The description confirms this with 'Takes no arguments,' matching the empty schema with additionalProperties:false, leaving no ambiguity about invocation.
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 and resource ('Returns the languages this Koboshi account is set to') and then enumerates the exact contents, so an agent knows precisely what comes back. It is clearly separable from sibling set_languages and the word-level lookup/save 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?
Explicitly names the alternative source of this data (connect-time instructions and the [account: ...] tag on every result) and the exact condition that selects this tool: 'the case where that list was missing or has just been changed.' It also rules out a plausible misconception by noting these languages are unrelated to device or conversation languages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns what Koboshi holds for a word, and the same word in every language on the account (the result names them). Koboshi's own card is used where it has one. Where it has none, the result carries Koboshi's rules for the word's card and for its card in each missing language; a second lookup carrying them in "card" and "translations" returns them checked, in one list, marked as written by the AI in the chat. Reads only: nothing is written or saved. save_word performs this lookup itself, so this tool is for looking a word up without keeping it. learning_language is the language the word is written in.
| Name | Required | Description | Default |
|---|---|---|---|
| card | No | The card written from Koboshi's card rules, when a result said the word is new to Koboshi. Checked and shown; stored nowhere. | |
| word | Yes | The word or short phrase, written in its own language. | |
| detail | No | brief (default) or full, when the user asks for more. | |
| translations | No | Cards for this word in the account's other languages, written from the translation card rules a result gave, one per language, each with "language". A lookup checks them and shows them; it stores nothing. | |
| primary_language | No | Language the meaning should be in. Defaults to the user's setting. | |
| learning_language | No | Language the word is in. Set it whenever you can tell. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description reinforces 'Reads only: nothing is written or saved' and adds meaningful behavioral context: a second lookup with card and translations returns them checked and marked as written by the AI. This goes beyond the structured safety profile.
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 front-loaded with what it returns and is appropriately sized for a complex tool, but sentences are dense and some ideas (e.g., the two-step validation) are interwoven. It is adequate but could be tightened without losing clarity.
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?
With no output schema, the description carries the burden of explaining return content. It describes the main result (cards and translations), the fallback when no card exists (rules for the word and missing languages), and the two-step validation. Some terms like 'Koboshi's rules' remain slightly vague, but overall it is complete enough to call correctly.
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 baseline is 3. The description adds value by explaining that card and translations are used in a second lookup to get checked results, and that learning_language is the language the word is written in. It clarifies the intended workflow for parameters that share the same names as return values.
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 verb (returns) and resource (what Koboshi holds for a word plus translations), and explicitly distinguishes itself from save_word. An agent can tell this is a read-only lookup tool without opening the schema.
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 names the key alternative (save_word) and the condition that selects this tool over it: 'save_word performs this lookup itself, so this tool is for looking a word up without keeping it.' It also explains the second-lookup pattern for filling in missing cards, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds one word, phrase or idiom to the user's own Koboshi vocabulary, so their spaced-repetition reviews bring it back. The word is saved in the one language it is written in. Koboshi looks it up as part of this call: when it already holds a card the save completes, and when it is new the result carries the card rules and the call is repeated with the finished card. Saving the same word twice does not create a second entry. One call saves the one word it was given and nothing else, unless "save_languages" names the words the user picked. Several different words from one request belong in save_words instead. A saved phrase or idiom counts one word for every 10 words it holds toward the account's 100-word daily limit, so a long one can use up more than one. The result shows the word in every language on the account, for reading. Cards Koboshi lacks are written by the AI in the chat from Koboshi's rules and sent in "translations"; Koboshi checks them and keeps them for its own review, and they add nothing to the vocabulary by themselves. Optional: "sense" names which meaning of an ambiguous word was wanted: a new word is saved with it, and a word already saved adds that meaning (its first meaning stays); "context_sentence" keeps the sentence the word appeared in as the user's own private example.
| Name | Required | Description | Default |
|---|---|---|---|
| card | No | The card you wrote, only needed when the word is new to Koboshi. | |
| word | Yes | The word, phrase or idiom to save, written in its own language. | |
| sense | No | Which meaning the user wants, in a few words, e.g. "the body-tissue sense, not the paper one". Only when they have said so. For a word they already saved it adds that meaning as one more, keeping the first. | |
| concept | No | The shared English label for this meaning, one word where one exists: "echo" covers yamabiko, eco and goonj alike. Koboshi links words carrying the same label, so the user sees this word beside the same concept in their other languages. | |
| translations | No | Cards for this word in the account's other languages, written from the translation card rules a result gave, one per language, each with "language". Koboshi keeps them for its check; they reach the vocabulary only through save_languages. | |
| save_languages | No | The languages of the words the user picked from the result: the word itself and its words in the account's other languages. Given, it is the whole list: the word in each language named is saved, and the word itself only when its own language is in the list. Left out, the save covers the one word. | |
| context_sentence | No | The sentence the word appeared in, when it came from text in this conversation. Kept as the user's own example on their saved word: private to them and never added to the shared dictionary. Up to 500 characters. | |
| primary_language | No | ||
| learning_language | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=true, openWorld=false), so the bar is lower; the description still adds real context: the two-phase lookup/save flow with card rules and repeat call, the quota rule (a phrase counts one word per 10 words toward the 100-word daily limit), and that translations are kept only for Koboshi's check. The idempotency sentence ('Saving the same word twice does not create a second entry') restates idempotentHint rather than adding to it.
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 core purpose is front-loaded in the first clause, but the description then becomes a dense wall of interleaved rules about quota, cards, translations and optional parameters. Given the tool's 9-parameter complexity some length is warranted, yet several sentences bundle multiple distinct rules and would read better as separated points.
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?
For a 9-parameter mutation with nested objects and no output schema, the description covers the important gaps: what the call returns on a new versus existing word, what the card-rules repeat call means, the quota impact, and the privacy of context_sentence. It stops short of describing failure modes or what to do if translation cards are rejected.
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?
With 78% schema coverage and rich per-parameter schema text, baseline is 3, but the prose adds meaning beyond it: sense distinguishes adding a new meaning from extending an existing one ('its first meaning stays'), save_languages is specified as a whole-list replacement behavior when supplied, and context_sentence is clarified as user-private with a 500-character limit.
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 and resource ('Adds one word, phrase or idiom to the user's own Koboshi vocabulary') and immediately distinguishes itself from save_words by routing multi-word requests elsewhere. An agent can identify the tool's job and its boundary against the closest sibling without opening a schema.
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?
Names the alternative for multi-word requests ('Several different words from one request belong in save_words instead') and explains that save_languages is the mechanism for saving the user's picked words. It lacks any guidance relative to lookup_word/get_languages and never states when not to save at all, so it is clear but not fully complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds several DIFFERENT words, phrases or idioms to the user's own Koboshi vocabulary in one request, for example a set of words from earlier in this conversation, sent together rather than one at a time. One word belongs in save_word, including a word wanted in more than one language. Each entry carries the language that word is written in. Words already in the vocabulary are reported as skipped; words new to Koboshi come back listed as needing a card, and cards sent with the first call are used straight away. Up to 50 items a call; a long phrase counts more than one of the account's 100-word daily limit, one word for every 10 words it holds. This connector can see only the current conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | No | One card per word, written from Koboshi's card rules. Send them with the first call when you already have the rules; otherwise the result lists which words still need one and you send those next. A card for a word Koboshi already knows is ignored, so sending extras is harmless. | |
| words | Yes | The words, phrases or idioms to save, at most 50 items. Each item is the word plus, when known, the language it is written in. A long phrase counts more than one toward the account's daily limit, one word for every 10 words it holds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly=false, destructive=false, idempotent=true, openWorld=false), yet the description still adds real behavioral depth: duplicate words are reported as skipped, new words come back flagged as needing a card, pre-supplied cards are consumed immediately, and the daily-limit accounting rule (a phrase consumes one word per 10 words toward the account's 100-word limit). This is disclosure well beyond the annotation set and is consistent with idempotentHint.
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-loaded with purpose and alternative routing, then behavior. Dense rather than padded, though the phrase-counts-toward-daily-limit rule is stated twice (in the description and again in the words schema entry), which is mild redundancy.
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?
There is no output schema, so the description carries the return-value burden — and it does, explaining both outcomes (skipped duplicates, words listed as needing a card). Combined with the batch limit, card-timing rule, and the connector's conversation-only visibility note, an agent has everything needed to call this correctly.
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 baseline is 3; the description reinforces but does not go far beyond the schema. It does clarify cross-parameter behavior the schema cannot express (cards for already-known words are ignored, extra cards are harmless; long phrases consume multiple limit units), which is why it holds at 3 rather than lower.
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 and resource ('Adds several DIFFERENT words, phrases or idioms to the user's own Koboshi vocabulary in one request') and explicitly routes the singular case to a named sibling: 'One word belongs in save_word'. An agent can separate this from save_word without opening either schema.
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 an explicit decision rule (this tool for sets from the conversation, save_word for a single word), plus the card-submission timing ('send them with the first call... otherwise the result lists which words still need one') and the batch bound ('Up to 50 items a call'). When-to-use and the alternative are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First-time setup for a Koboshi account that has no languages yet: the language meanings are written in, the language being learned, up to four more the user knows or is also learning, and the month and year the user was born, which Koboshi asks every new account, as its website does. It applies to an account still waiting to be set up. An account whose languages are already chosen keeps them, and the result says what they are; a change to them happens in the Koboshi app, under Settings.
| Name | Required | Description | Default |
|---|---|---|---|
| birth_year | No | The year the user was born in, four digits, from the user's own answer in this conversation. Asked once, when the account is first set up. | |
| birth_month | No | The month the user was born in, 1 to 12, from the user's own answer in this conversation. Asked once, when the account is first set up. | |
| learning_level | No | Rough level in the main language, if the user says. | |
| primary_language | Yes | Language the user wants meanings and notes in. | |
| learning_language | Yes | The main language they are learning. | |
| secondary_languages | No | Up to four more languages they know or are also learning. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, readOnlyHint=false, so safety is covered. The description adds real context beyond that: repeat calls are a no-op that preserves existing values, the result echoes the current languages, and modifications must happen outside this tool. It stops short of describing error behavior or the birth-date requirement's consequences.
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 purpose is front-loaded, but the second and third clauses are padded ('which Koboshi asks every new account, as its website does') and the field enumeration duplicates the schema. Content is useful but not tight.
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?
For a mutation tool with full annotation coverage, no output schema, and fully documented parameters, the description covers preconditions, idempotent repeat behavior, and where the result lands. Only edge cases (validation errors, missing birth data) are unaddressed, which is a minor gap.
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 every parameter and the enum values. The description restates most fields (meanings language, learning language, secondary languages, birth month/year) but omits learning_level and adds no format or constraint detail beyond the schema. Baseline 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 names a specific verb and resource (first-time setup writing the account's languages) and enumerates the fields involved, so an agent knows exactly what is being set. It does not name the sibling get_languages to distinguish read vs write, but the purpose itself is clear.
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 states the precondition explicitly ('first-time setup for a Koboshi account that has no languages yet' / 'still waiting to be set up') and the when-not ('an account whose languages are already chosen keeps them'), then routes existing-language changes to the app's Settings rather than this tool. This is unusually complete routing guidance.
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.
lookup_word1 field changedInput schema / properties / primary_language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]save_word1 field changedInput schema / properties / primary_language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]set_languages1 field changedInput schema / properties / primary_language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]lookup_word2 fields changedInput schema / properties / learning_language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]Input schema / properties / translations / items / properties / language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]save_word3 fields changedInput schema / properties / learning_language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]Input schema / properties / save_languages / items / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]Input schema / properties / translations / items / properties / language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]save_words1 field changedInput schema / properties / words / items / properties / learning_language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]set_languages2 fields changedInput schema / properties / learning_language / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]Input schema / properties / secondary_languages / items / enumPrevious value: -[
- "en",
- "es",
- "ja",
- "de",
- "ko",
- "zh",
- "ur",
- "hi",
- "pt",
- "fr",
- "it",
- "ru",
- "nl",
- "tr",
- "vi",
- "fil",
- "bn",
- "nb",
- "ar",
- "id",
- "th"
-]New value: +[
+ "en",
+ "es",
+ "ja",
+ "de",
+ "ko",
+ "zh",
+ "ur",
+ "hi",
+ "pt",
+ "fr",
+ "it",
+ "ru",
+ "nl",
+ "tr",
+ "vi",
+ "fil",
+ "bn",
+ "nb",
+ "ar",
+ "id",
+ "th",
+ "kk",
+ "fa"
+]save_word1 field changedInput schema / properties / word / descriptionAdded value: +"The word, phrase or idiom to save, written in its own language."save_words2 fields changedInput schema / properties / words / descriptionPrevious value: -"The words to save, at most 50. Each item is the word plus, when you know it, the language THAT word is in."New value: +"The words, phrases or idioms to save, at most 50 items. Each item is the word plus, when known, the language it is written in. A long phrase counts more than one toward the account's daily limit, one word for every 10 words it holds."Input schema / properties / words / items / properties / word / descriptionAdded value: +"The word, phrase or idiom, in its own language."get_languageslookup_wordsave_wordsave_wordsset_languagesFree: turn your AI chats into spaced-repetition vocabulary. 13 tools, reads and writes.
Spaced-repetition flashcards your AI writes, quizzes you on by voice, and schedules with FSRS.
Language flashcards in your AI assistant: build decks, edit cards and review what's due in the chat.
Voice-led, FSRS-scheduled flashcards from YouTube, PDFs, web, or text. Auto-graded quizzes.
Add one secure layer between your agents and this server.
