Skip to main content
Glama
Sign In
Gujarati Lexicon MCP Server

Gujarati Lexicon MCP Server

by aarshbharat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Gujarati Lexicon MCP Server PyPI

A grounded Gujarati dictionary for AI assistants. Connect it to Claude (or any MCP client) and the assistant looks Gujarati words up in real dictionary data instead of guessing: meanings, synonyms, idioms (રૂઢિપ્રયોગ), and inflected forms like ઘરમાં or આંખોમાં.

Why this exists: LLMs are unreliable with Gujarati. They invent meanings, mix up idioms, and produce convincing but wrong usage. This server gives the model facts to stand on and tells it plainly when a word is not in the dictionary.

Demo

Example

User: અમે નો અર્થ શું છે?

Claude (after calling define): અમે means "we", the plural of હું (I)…

User: ઘરમાં નો અર્થ?

Claude: ઘરમાં = ઘર + માં → "in the house". The server matched the inflected form to its base word ઘર.

Related MCP server: Dictionary By Api Ninjas

Features

Primitive

Name

What it does

Tool

define(word)

Meanings, part of speech, examples, transliteration

Tool

synonyms(word)

Synonyms (સમાનાર્થી શબ્દો) from all sources, deduplicated

Tool

idioms(word)

Idioms (રૂઢિપ્રયોગ) containing the word; never invents any

Resource

lexicon://word-of-the-day

A daily word from the hand-checked set

Prompt

explain_passage

Explains a Gujarati passage word by word using the tools

  • About 6,800 words with English meanings, from Wiktionary

  • Hand-checked entries with Gujarati meanings and idioms (curated set, growing)

  • Inflection handling: ઘરમાં, ઘરે, આંખોમાં, and અમે resolve to their base words

  • "Did you mean?" suggestions for typos (પાણિ → પાણી)

  • Source attribution in every response, so the assistant can say where a meaning came from

Quick start

Requires uv.

Add this to your Claude Desktop config (Settings → Developer → Edit Config):

      "args": ["gujarati-lexicon-mcp"]

Restart Claude Desktop completely (quit from the system tray), open a new chat, and ask about any Gujarati word.

On Windows, if Claude Desktop can't find uvx, use its full path (find it with where uvx), e.g. C:\\Users\\<you>\\.local\\bin\\uvx.exe.

How lookup works

A word goes through three layers, from most to least reliable:

flowchart LR
    A[Input word] --> B{Exact headword?}
    B -- yes --> C{Pure inflected form?}
    C -- yes --> D[Follow Wiktionary link<br/>ઘરે → ઘર]
    C -- no --> E[Return entry]
    D --> E
    B -- no --> F[Strip suffixes<br/>માં, નો, ની, ે, ો ...]
    F -- match --> E
    F -- no match --> G[Not found + suggestions<br/>tell the model not to guess]

  1. Exact match. A real dictionary entry always wins over a guessed base form.

  2. Wiktionary inflection links. Wiktionary records that ઘરે is the locative of ઘર. The converter reads the structured form_of field, and falls back to parsing glosses like "plural of X" where that field is missing.

  3. Suffix stripping. As a last resort, common endings are removed (up to two, e.g. આંખોમાં → આંખો → આંખ). A stripped form is accepted only if it is a real headword, so words are never mangled.

Responses keep sources separate (curated vs wiktionary_senses), so the model can attribute meanings honestly.

Data sources

Source

Provides

License

curated.json

Gujarati meanings, idioms, synonyms (hand-checked)

MIT (this project)

wiktionary.json

~6,800 words: English meanings, transliterations, synonyms, inflection links

CC BY-SA

Wiktionary data comes from Wiktionary via kaikki.org, extracted with wiktextract:

Tatu Ylonen. Wiktextract: Wiktionary as Machine-Readable Structured Data. Proceedings of the 13th Conference on Language Resources and Evaluation (LREC), pp. 1317–1325, 2022.

Rebuilding the Wiktionary data

The raw dump is not committed. To regenerate wiktionary.json:

mkdir -p data/raw
curl -L -o data/raw/kaikki-gujarati.jsonl "https://kaikki.org/dictionary/Gujarati/kaikki.org-dictionary-Gujarati.jsonl"
uv run python scripts/build_wiktionary.py

The converter groups entries by word, keeps only what the tools need (20 MB → a compact JSON file), drops non-Gujarati-script headwords, and records inflection links.

Development

git clone https://github.com/aarshbharat/gujarati-lexicon-mcp
cd gujarati-lexicon-mcp
uv sync
uv run pytest -v                                    # run tests
uv run mcp dev src/gujarati_lexicon_mcp/server.py   # open MCP Inspector

Project layout:

src/gujarati_lexicon_mcp/
├── server.py           # MCP server: tools, resource, prompt
└── data/               # dictionary data shipped with the package
scripts/build_wiktionary.py   # raw kaikki dump → wiktionary.json
tests/                        # pytest

Known limitations

  • Verb forms are only partly covered: forms Wiktionary links (e.g. હોઈશ → હોવું) work, but phrases like લે છે are not lemmatized.

  • Wiktionary synonyms are merged across senses. ઘર's list includes ઓફિસ (from its "office" sense). The tool tells the model this.

  • The curated set is small. Most entries have English meanings only; Gujarati-language meanings and idioms come from the hand-checked data.

  • Grounding covers facts, not everything the model says. The model may add correct background from its own knowledge (e.g. the inclusive/exclusive "we" distinction for અમે/આપણે). The server's instructions ask it to label general knowledge, but cannot force it.

PyPI

Roadmap

  • Grow the curated set, especially idioms and proverbs (કહેવત)

  • Sense-level synonyms instead of a merged list

  • Better verb lemmatization

  • Streamable HTTP transport and a hosted endpoint

  • Publish to PyPI and the MCP Registry

License

Built by Aarsh Dhokai · AI × AI: Artificial Intelligence × Aarsh India

Available Tools

3 tools
defineA

Look up the meaning of a Gujarati word in the dictionary.

Use this whenever the user asks what a Gujarati word means, its part of speech, or how it is used in a sentence. Pass the word in Gujarati script (e.g. 'પાણી'), not in romanized form. Inflected forms (e.g. 'આંખોમાં') are matched to their base word.

NameRequiredDescriptionDefault
wordYes

TDQS

A3.8/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. It usefully discloses one non-obvious behavior (inflected forms like 'આંખોમાં' are matched to their base word) and the script constraint, but says nothing about not-found handling, result size, or whether the lookup is a live or cached/single-source dictionary.

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?

Three short sentences, front-loaded with the purpose, then usage, then input format. No filler, though the script and inflection notes could be consolidated into one input-format sentence.

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 one-parameter read-only lookup with no annotations and no output schema, the description covers purpose, triggers, input format, and one normalization behavior, and it enumerates the kinds of information returned (meaning, part of speech, usage). Only not-found behavior and result shape remain unstated, which is a minor gap.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate, and it does: it specifies the required script (Gujarati, e.g. 'પાણી'), forbids romanized input, and notes that inflected forms are normalized. That is meaningful guidance well beyond a bare "Word" string field.

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?

"Look up the meaning of a Gujarati word in the dictionary" gives a specific verb (look up) and resource (dictionary entry) with a clear language qualifier. It does not explicitly name the siblings (synonyms, idioms) or state what it is not, so an agent must infer the boundary from the word "meaning" alone.

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 names concrete triggering conditions: the user asks what a word means, its part of speech, or how it is used in a sentence. It gives no explicit exclusion against the synonyms/idioms siblings, but the positive triggers are specific enough to route most requests.

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

idiomsA

Find Gujarati idioms (રૂઢિપ્રયોગ) that contain a given word.

Use this when the user asks for idioms, phrases, or sayings involving a Gujarati word. Searches across the whole dictionary, so it also finds idioms listed under other words. Pass the word in Gujarati script.

NameRequiredDescriptionDefault
wordYes

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations present, the description carries the full behavioral burden. It usefully discloses that the search spans the whole dictionary and therefore surfaces idioms listed under other words, plus the Gujarati-script input requirement. It says nothing about return shape, match semantics (substring vs. token), or what happens when no idiom is found.

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?

Three short sentences, purpose front-loaded, then the usage trigger, then the input-format and scope notes. Each sentence contributes something distinct and nothing is padded.

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 single-parameter lookup with no annotations and no output schema, the description covers purpose, trigger, search scope, and input encoding. The only real gap is expected result content, which is minor for a lookup tool of this simplicity.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does: 'Pass the word in Gujarati script' is a hard input-format constraint not in the schema, and 'idioms that contain a given word' clarifies the match is containment-based. It stops short of specifying transliteration handling or partial-word behavior.

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 opens with a specific verb and resource ('Find Gujarati idioms (રૂઢિપ્રયોગ) that contain a given word'), which is unambiguous and even supplies the native-language term for disambiguation. It does not name or contrast with the siblings 'define' and 'synonyms', so an agent must infer the split from the noun 'idioms' alone.

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?

'Use this when the user asks for idioms, phrases, or sayingings involving a Gujarati word' gives a concrete trigger condition covering the natural phrasings. It also clarifies the search is dictionary-wide rather than headword-scoped. No explicit when-not or sibling comparison is provided, which keeps it below a 5.

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

synonymsA

Get synonyms (સમાનાર્થી શબ્દો) for a Gujarati word.

Use this when the user asks for similar words, alternatives, or another way to say a Gujarati word. Pass the word in Gujarati script.

NameRequiredDescriptionDefault
wordYes

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the input constraint that the word must be in Gujarati script, but says nothing about the return shape (a list? grouped by sense?), handling of unknown or transliterated words, or errors.

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 before usage guidance, and the Gujarati-script gloss (સમાનાર્થી શબ્દો) adds clarity without bloat. Nothing is wasted.

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 one-parameter lookup tool with no output schema, this covers purpose, trigger conditions, and the script requirement. The remaining gap is what the response looks like and how edge cases (unknown words, mixed-script input) behave.

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

Parameters4/5

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

Schema coverage is 0% — the parameter is only described as a generic string titled 'Word'. The description meaningfully compensates by requiring the value in Gujarati script, which is a real constraint an agent would otherwise miss.

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?

States a specific verb and resource ('Get synonyms ... for a Gujarati word') and scopes it to Gujarati, which cleanly separates it from the define and idioms siblings. An agent can pick this 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.

Usage Guidelines4/5

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

Gives explicit triggering conditions: user asks for similar words, alternatives, or another way to say a Gujarati word. It does not name the alternatives (define, idioms) or state when not to use it, so routing to siblings is left slightly implicit.

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. 3 tool updatesv0.2.1
    • First observeddefine
    • First observedidioms
    • First observedsynonyms
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

A4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a clearly distinct lookup type: definitions, synonyms, and idioms. An agent can easily select the right tool based on user intent, with no overlapping purposes.

Naming Consistency4/5

Names are simple and readable, but the convention is mixed: 'define' is a verb while 'synonyms' and 'idioms' are nouns. This is a minor deviation, not confusing.

Tool Count4/5

Three tools is lean but reasonable for a focused dictionary server. However, it feels slightly under-scoped given that a lexicon could support additional common operations like antonyms or example sentences.

Completeness4/5

The surface covers core lexicon lookups (definition, synonyms, idioms) with no dead ends for those tasks. Minor gaps remain, such as antonyms, pronunciation, or example sentences, which agents can work around but would be natural additions.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Related MCP Servers