Skip to main content
Glama
satish-kori-27

Swedish Language Learning MCP Server

by satish-kori-27
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Swedish Language Learning MCP Server 🇸🇪

License: MIT TypeScript MCP

An MCP (Model Context Protocol) server for learning Swedish language, providing tools for vocabulary, grammar, translations, and practice exercises. Perfect for integration with AI assistants like Claude, VS Code Copilot, and other MCP-compatible clients.

Features

🔤 Translation Tool

  • Translate between Swedish and English

  • Auto-detect source language

  • Extensive vocabulary database

📚 Vocabulary Tools

  • 100+ common Swedish words and phrases

  • Categories: greetings, verbs, nouns, adjectives, numbers, colors, animals

  • Searchable vocabulary database

📖 Grammar Help

  • Noun gender (en-words and ett-words)

  • Definite forms

  • Word order (V2 rule)

  • Pronunciation guide (å, ä, ö, sje-sound)

  • Present tense verbs

💬 Common Phrases

  • Greetings and introductions

  • Everyday phrases

  • Food and dining phrases

  • Includes pronunciation guides

✏️ Practice Exercises

  • Translation exercises

  • Vocabulary matching

  • Grammar drills

  • Multiple difficulty levels

Related MCP server: ExamPrepAgent

Installation

Prerequisites

  • Node.js 18+ and npm

Quick Start

  1. Clone the repository:

git clone https://github.com/YOUR_USERNAME/swedish-language-mcp-server.git
cd swedish-language-mcp-server

  1. Install dependencies:

npm install

  1. Build the server:

npm run build

Usage

Configuration

Add this server to your MCP client configuration. For VS Code, add to .vscode/mcp.json:

{
  "servers": {
    "swedish-language": {
      "type": "stdio",
      "command": "node",
      "args": [
        "/absolute/path/to/swedish-language-mcp-server/build/index.js"
      ]
    }
  }
}

For Claude Desktop, add to your MCP settings file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "swedish-language": {
      "command": "node",
      "args": [
        "/absolute/path/to/swedish-language-mcp-server/build/index.js"
      ]
    }
  }
}

Running the Server

The server is configured to run via the MCP configuration. Once built, it will be available through your MCP client.

Available Tools

  1. translate_swedish - Translate words/phrases between Swedish and English

  2. get_vocabulary - Browse Swedish vocabulary by category

  3. grammar_help - Learn Swedish grammar rules

  4. common_phrases - Get common Swedish phrases with pronunciation

  5. practice_exercise - Generate practice exercises

  6. ask_swedish - Ask questions in natural language (perfect for voice input!)

Tool Examples

Translate a word

{
  "tool": "translate_swedish",
  "arguments": {
    "text": "får",
    "from": "swedish"
  }
}

Get vocabulary

{
  "tool": "get_vocabulary",
  "arguments": {
    "search": "cat"
  }
}

Learn grammar

{
  "tool": "grammar_help",
  "arguments": {
    "topic": "noun-gender"
  }
}

Practice

{
  "tool": "practice_exercise",
  "arguments": {
    "type": "translation",
    "difficulty": "beginner"
  }
}

Natural Language Questions (Voice-Friendly)

{
  "tool": "ask_swedish",
  "arguments": {
    "question": "How do you say good morning in Swedish?"
  }
}

Features in Detail

🔤 Comprehensive Vocabulary

  • 100+ common Swedish words and phrases

  • Categories: greetings, verbs, nouns, adjectives, numbers, colors, animals

  • Searchable database with English translations

📖 Grammar Explanations

  • Noun gender (en-words and ett-words)

  • Definite forms and articles

  • Word order (V2 rule)

  • Pronunciation guide (å, ä, ö, sje-sound)

  • Present tense verb conjugations

💬 Common Phrases

  • Greetings and introductions

  • Everyday conversational phrases

  • Food and dining expressions

  • Complete with pronunciation guides

✏️ Interactive Practice

  • Translation exercises

  • Vocabulary matching games

  • Grammar drills

  • Multiple difficulty levels

🎤 Voice Input Support

  • Natural language processing

  • Conversational query understanding

  • Optimized for spoken questions

Contributing

Contributions are welcome! Please feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.

Development Setup

  1. Fork the repository

  2. Create your feature branch: git checkout -b feature/amazing-feature

  3. Make your changes

  4. Build and test: npm run build

  5. Commit your changes: git commit -m 'Add amazing feature'

  6. Push to the branch: git push origin feature/amazing-feature

  7. Open a Pull Request

Adding New Vocabulary

To add new vocabulary, edit the vocabularyDatabase object in index.ts:

const vocabularyDatabase = {
  common: {
    "swedish_word": "english_translation",
    // Add more words here
  }
};

Roadmap

  • Add more verb conjugations

  • Expand vocabulary to 500+ words

  • Add audio pronunciation support

  • Implement spaced repetition exercises

  • Add Swedish-to-English quiz mode

  • Support for advanced grammar topics

Resources

License

This project is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

Support

If you find this project helpful, please consider:

  • ⭐ Starring the repository

  • 🐛 Reporting bugs

  • 💡 Suggesting new features

  • 🤝 Contributing to the codebase

Lycka till med din svenska! (Good luck with your Swedish!) 🇸🇪

Available Tools

6 tools
ask_swedishB

Ask any question about Swedish in natural language. Perfect for voice input. Examples: 'How do you say hello?', 'What does kunna mean?', 'Conjugate the verb gå', 'Tell me about Swedish pronunciation'

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYesYour question about Swedish language in natural conversational form

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it discloses only that input is natural conversational language suited to voice. It says nothing about response format, latency, confidence, or limitations of the 'any question' claim. The voice/natural-language note is genuine added context, but far from complete for a QA 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?

Purpose is front-loaded in the first sentence, followed by a usage hint and four compact examples. No filler, though the example list is slightly longer than needed to convey the tool's breadth.

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 one-parameter, low-complexity tool with full schema coverage and no output schema, the description is adequate. Its main gap is contextual: with five overlapping siblings, it never clarifies when this general-purpose asker should be preferred over grammar_help or translate_swedish.

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% for the single 'question' parameter, so the schema already documents its type and conversational form. The examples add a little color about what shapes a question can take, but nothing beyond what the schema conveys; baseline 3 applies.

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 states a specific verb and resource ('ask any question about Swedish') and the examples concretize the domain (translation, definitions, conjugation, pronunciation). However, it never distinguishes itself from siblings like grammar_help, translate_swedish, or get_vocabulary, which the examples clearly overlap with, so an agent cannot route confidently from the description alone.

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?

'Perfect for voice input' implies a usage context (spoken/natural-language queries), which is a real hint. But there is no explicit when-to-use/when-not-to-use guidance and no named alternative for cases better served by grammar_help or translate_swedish, so the routing decision is left to inference.

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

common_phrasesB

Get common Swedish phrases with translations and pronunciation guides.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoCategory of phrasesall

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. 'Get' implies a read-only lookup and the description discloses that results include translations and pronunciation guides, but it omits category filtering behavior, default handling, and any safety or rate-limit context.

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 no wasted words. It is appropriately sized for this simple tool.

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

Completeness3/5

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

For a simple one-parameter lookup tool, the description explains the return content and schema covers the category filter. However, it lacks sibling differentiation and usage context, leaving clear gaps for an agent choosing among Swedish-learning 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?

Schema description coverage is 100%, so the single 'category' parameter is already documented with an enum and default. The description adds no parameter semantics beyond what the schema provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get') and resource ('common Swedish phrases') plus return content ('translations and pronunciation guides'). It does not distinguish this tool from siblings like get_vocabulary or translate_swedish, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus translate_swedish, get_vocabulary, or other siblings. The description only states what it does, leaving all usage decisions to inference.

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

get_vocabularyA

Get Swedish vocabulary words with translations and examples. Can filter by category.

ParametersJSON Schema
NameRequiredDescriptionDefault
searchNoSearch for specific words (optional)
categoryNoCategory of vocabulary to retrieveall

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose the return content (translations plus examples), which is helpful, but says nothing about result volume, pagination, or whether the list is static or generated.

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 short sentences, front-loaded with purpose, with zero filler. Every clause carries information.

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 simple two-parameter read tool with no output schema, the description adequately covers what comes back (words, translations, examples). It is nearly complete; only return volume/limits are unaddressed.

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 both parameters are already documented with an enum and default for category. The description's mention of category filtering adds nothing beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ('Get Swedish vocabulary words') and even names the return payload (translations and examples). It does not, however, distinguish itself from siblings like common_phrases, which could plausibly return similar content.

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?

'Can filter by category' implies the retrieval use case but gives no when-to-use guidance, no exclusions, and no routing to alternatives such as common_phrases or translate_swedish. Usage is only inferable.

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

grammar_helpB

Get explanations of Swedish grammar rules and patterns.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicYesGrammar topic to learn about

TDQS

B3.3/5.0
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, and it discloses only that the tool returns explanations. For a low-risk read-only lookup this is acceptable, but it omits any mention of output format (prose vs structured) or depth of explanation.

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?

A single front-loaded sentence with no wasted words, appropriately sized for a simple one-parameter lookup tool.

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

Completeness3/5

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

For a simple retrieval tool with a fully documented enum parameter and no output schema, the description is minimally adequate. It stops short of clarifying how results are returned or how it relates to the overlapping 'ask_swedish' sibling.

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% and the 'topic' parameter is fully enumerated with six values, so the schema does the heavy lifting. The description adds no meaning beyond what the schema already documents, which is the baseline expectation.

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 states a specific verb ('Get explanations') and resource ('Swedish grammar rules and patterns'), making the tool's function clear. It does not, however, differentiate itself from the sibling 'ask_swedish', which could plausibly answer grammar questions too.

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?

There is no guidance on when to use this tool versus alternatives like ask_swedish or practice_exercise. No conditions, prerequisites, or exclusions are given, leaving the agent to infer routing from the name alone.

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

practice_exerciseC

Generate practice exercises for learning Swedish (translation, fill-in-the-blank, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesType of exercise to generate
difficultyNoDifficulty levelbeginner

TDQS

C2.9/5.0
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 doesn't disclose whether exercises require prior input, whether they're static or adaptive, what format the output takes, or any limits. Only the basic action is implied.

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?

A single efficient sentence with no waste, though it could front-load the purpose more directly. It's appropriately sized for a simple tool.

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

Completeness3/5

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

For a 2-param tool with no annotations and no output schema, the description is minimal but covers the core purpose. It lacks behavioral details and usage context that would help an agent invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no param-specific details beyond 'type' examples, which are already covered. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb+resource: generate practice exercises for learning Swedish, with examples of exercise formats. It doesn't differentiate from siblings like grammar_help or get_vocabulary, but the purpose is specific enough.

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 when-to-use or when-not-to-use guidance is provided. The description doesn't mention alternatives or context for selecting this tool over siblings like grammar_help or get_vocabulary.

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

translate_swedishB

Translate between Swedish and English. Provide a word or phrase in either language.

ParametersJSON Schema
NameRequiredDescriptionDefault
fromNoSource language (auto-detect if not specified)auto
textYesThe Swedish or English text to translate

TDQS

B3.3/5.0
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 behavioral burden. It conveys bidirectionality but says nothing about how direction is resolved, output format, confidence, or behavior with unknown words — all relevant for a translation 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?

Two short sentences, front-loaded with the core capability followed by the input expectation. Every clause earns its place and there is no filler.

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 low-complexity two-parameter tool with a fully described schema and no output schema, the description is minimally adequate. However, with no annotations it should do more to cover direction handling, output expectations, and sibling differentiation.

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 'from' enum and 'text' both fully documented in the schema, so the baseline is 3. The description's mention of 'either language' merely echoes the bidirectional capability already expressed by the 'from' enum, adding no new meaning.

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?

States a specific verb ('Translate') and a bounded resource pair ('between Swedish and English'), so an agent knows exactly what the tool does. It stops short of differentiating from the sibling 'ask_swedish', which could plausibly also produce Swedish-language output, leaving that overlap to inference.

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 phrase 'Provide a word or phrase in either language' implies the tool's input scope (short units, bidirectional), which is implicit usage guidance. It never states when to prefer this over 'ask_swedish' or 'get_vocabulary', and offers no exclusions or prerequisites.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv1.0.0
    • First observedask_swedish
    • First observedcommon_phrases
    • First observedget_vocabulary
    • First observedgrammar_help
    • First observedpractice_exercise
    • First observedtranslate_swedish
Deploy Server
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

TDQS

B3.4/5.0

Scored across 6 tools

Disambiguation4/5

Each tool targets a distinct learning need: translation, vocabulary, grammar, phrases, exercises, and open Q&A. However, ask_swedish is a general-purpose catch-all that overlaps with the more specialized translate_swedish, get_vocabulary, grammar_help, and common_phrases, creating some risk of misselection when a specific tool would suffice.

Naming Consistency3/5

All names use snake_case, but the verb-first (translate_swedish, get_vocabulary, ask_swedish) and noun-first (grammar_help, common_phrases, practice_exercise) patterns are mixed. It's readable and consistent in case, but not a single predictable convention.

Tool Count5/5

Six tools is well within the ideal range and each provides a distinct capability for a language-learning server. No obvious redundancy or missing critical function based on count alone.

Completeness4/5

The surface covers core areas: translation, vocabulary, grammar, phrases, practice, and a Q&A fallback. No dedicated pronunciation or progress-tracking tools, but pronunciation is embedded in common_phrases and ask_swedish can handle many ad-hoc requests, so gaps are minor.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers