Skip to main content
Glama
arnizamani

arabic-dict-mcp

by arnizamani
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

arabic-dict-mcp

Python 3.10+ MCP License: MIT

An MCP server that gives AI agents grounded Arabic dictionary lookup — so replies about words, roots, and meanings come from real dictionary data instead of the model's parametric memory.

Built for Arabic learners who are tired of AI assistants confidently inventing meanings, roots, and derivations.

Why

Ask any LLM "what's the root of مكتوب and its siblings?" and you'll get an answer that sounds right — sometimes it is, often it isn't. This server exposes three tools the model can call to look words up in real dictionaries. When wired into Claude Code, Claude Desktop, or any MCP-compatible client, the model grounds its answer in the returned data instead of guessing.

Related MCP server: multilingual-dictionary-mcp

Tools

Tool

What it does

lookup_root(root)

All dictionary entries under a root. Accepts any form: كتب, ك-ت-ب, كَتَبَ.

lookup_word(word)

Matches an inflected surface form or lemma. Returns each match's root so the agent can pivot to lookup_root for siblings.

search_meaning(query, lang="en"|"ar")

Full-text search over meanings for "what's the root for X?" style questions.

Diacritics. Input is tashkeel-insensitive — كَاتِبٌ, كاتب, and كَاتِب all match. Output preserves full vocalization from the source (including final case marks), because the vowelled form is what disambiguates the lemma.

Data sources

Downloaded at build time by scripts/build_dataset.py; not vendored in the repo.

Source

Coverage

License

linuxscout/arramooz

~40k MSA verb & noun entries — root, POS, wazn, forms, Arabic definitions

GPL

aliozdenisik/quran-arabic-roots-lane-lexicon

1,651 Quranic roots with English (Lane) glosses

GPLv3

Total: 5,610 roots · 42,351 entries in a unified SQLite index with FTS5.

Optional: Hans Wehr (personal use)

The classic Hans Wehr Arabic–English Dictionary has full entries with principal parts (past + present + maṣdar) inline — e.g. kataba u (katb, كتبة kitba, كتابة kitāba) to write, …. Passing --hanswehr to the builder adds ~25k Hans Wehr entries.

.venv/bin/python scripts/build_dataset.py --hanswehr

The underlying dictionary is copyrighted (Otto Harrassowitz / Spoken Language Services). The transcription downloaded lives in GibreelAbdullah/HansWehrDictionary and ships without a license file. Use of --hanswehr is at your own discretion for personal use only — this repo does not ship the data, does not commit it, and does not encourage redistributing the resulting data/arabic.db.

If you already have a copy locally, point the flag at it:

.venv/bin/python scripts/build_dataset.py --hanswehr /path/to/hanswehr.sqlite

Install

git clone https://github.com/arnizamani/arabic-dict-mcp.git
cd arabic-dict-mcp
uv venv .venv
uv pip install --python .venv/bin/python -e .
.venv/bin/python scripts/build_dataset.py    # ~40 MB download → data/arabic.db

Use — Claude Code / Desktop (stdio)

claude mcp add arabic-dict \
  -- /absolute/path/arabic-dict-mcp/.venv/bin/python -m arabic_dict_mcp.main

Or add to ~/.claude/mcp.json / claude_desktop_config.json:

{
  "mcpServers": {
    "arabic-dict": {
      "command": "/absolute/path/arabic-dict-mcp/.venv/bin/python",
      "args": ["-m", "arabic_dict_mcp.main"]
    }
  }
}

Then ask Claude something like "What's the root of مكتوب and what other words come from it?" — the model will call lookup_word → lookup_root and reply with grounded data.

From a Windows client, server in WSL

Point command at wsl.exe and give the interpreter its Linux path:

{
  "mcpServers": {
    "arabic-dict": {
      "command": "wsl.exe",
      "args": [
        "-e",
        "/mnt/c/path/to/arabic-dict-mcp/.venv/bin/python",
        "-m",
        "arabic_dict_mcp.main"
      ]
    }
  }
}

If the client reports ClosedResourceError, the pipe to the server died rather than a tool failing — usually the WSL VM cold-starting past the client's startup timeout. Run any wsl.exe echo hi first to warm the VM, then retry.

Debug — MCP Inspector

The server is a silent stdio daemon: it prints nothing on startup and waits for newline-delimited JSON-RPC on stdin. To poke at it interactively, use the MCP Inspector rather than running it bare.

npx @modelcontextprotocol/inspector .venv/bin/python -m arabic_dict_mcp.main

Open the URL it prints — it carries a pre-filled session token, and the bare http://localhost:6274 will fail auth. Then Connect → Tools → List Tools.

Against a git worktree (where data/ is gitignored and absent), point at the source and a real database:

PYTHONPATH=$PWD/src \
ARABIC_MCP_DB=/path/to/arabic-dict-mcp/data/arabic.db \
npx @modelcontextprotocol/inspector \
  /path/to/arabic-dict-mcp/.venv/bin/python -m arabic_dict_mcp.main

From Windows, mirror whatever the client uses so the same wsl.exe hop is exercised:

npx @modelcontextprotocol/inspector wsl.exe -e /mnt/c/path/to/arabic-dict-mcp/.venv/bin/python -m arabic_dict_mcp.main

For HTTP mode, start the server yourself, then launch a bare npx @modelcontextprotocol/inspector and connect to http://127.0.0.1:8000/mcp with transport Streamable HTTP.

Driving stdio by hand

No inspector needed — pipe the handshake in, but keep stdin open. On EOF the server shuts down, so a plain heredoc answers initialize and then exits before later replies arrive; the trailing sleep is what makes them show up.

{ printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"lookup_root","arguments":{"root":"كتب"}}}'
  sleep 5
} | .venv/bin/python -m arabic_dict_mcp.main

Order matters: initialize, then the initialized notification, then real calls. Note that stdout is protocol-only — any stray print() in server code corrupts the framing and the client drops the connection, so logs must go to stderr.

Use — HTTP (remote)

.venv/bin/python -m arabic_dict_mcp.main --http --port 8000

By default, HTTP is unauthenticated — fine for localhost testing. For anything on the public network, set a bearer token first:

export MCP_AUTH_TOKEN=$(openssl rand -hex 24)
.venv/bin/python -m arabic_dict_mcp.main --http --host 0.0.0.0 --port 8000

When MCP_AUTH_TOKEN is set, clients must send Authorization: Bearer $MCP_AUTH_TOKEN.

Test

PYTHONPATH=src .venv/bin/python -m pytest tests/

Layout

src/arabic_dict_mcp/
  normalize.py   diacritic + letter-variant normalization (pyarabic)
  db.py          SQLite queries: lookup_root / lookup_word / search_meaning
  server.py      MCPServer with the three tools registered
  main.py        --http | stdio entrypoint
scripts/
  build_dataset.py   downloads sources → unified data/arabic.db with FTS5
tests/
  test_normalize.py

Known limits

  • English meanings only cover the ~1,651 Quranic roots. Other MSA vocabulary returns terse Arabic glosses from arramooz only.

  • arramooz definitions are short dictionary glosses, not full lexicon entries. A future version could bring in the full Lane's Lexicon (Perseus XML) for classical coverage.

  • License asymmetry: this repository's code is MIT, but the downloaded dictionary data is GPL/GPLv3. Redistributing the built data/arabic.db triggers GPL; the code alone doesn't.

Contributing

Issues and pull requests are welcome. Ideas that would help:

  • Full Lane's Lexicon ingestion beyond Quranic roots

  • Additional MSA/dialect dictionaries with permissive licenses

  • Root-similarity or fuzzy matching for typo tolerance

License

MIT — see LICENSE for details. Note the data-license asymmetry above.

Available Tools

3 tools
lookup_rootA

Look up an Arabic root and return all dictionary entries under it.

Accepts a root in any form: "كتب", "ك ت ب", "ك-ت-ب", or with diacritics like "كَتَبَ". Diacritics and letter-variants (ا/أ/إ/آ, ي/ى, ه/ة) are normalized before matching. Use this when the user has already identified the root or when you want to see all sibling words for a lemma.

Returns entries from three sources:

  • arramooz-verb: verb lemma with tense-availability flags in extra

  • arramooz-noun: noun / adjective / participle with wordtype, pattern (wazn), gender/number, and a terse Arabic definition

  • lane-quran: English (and Turkish) semantic gloss from Lane's Lexicon for the ~1,651 roots that occur in the Quran

All returned Arabic words are fully vocalized (tashkeel is preserved from the source, including final case marks) so the caller can tell homographs apart. Input is diacritic-insensitive; output is not.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full transparency burden and excels. It discloses normalization of diacritics and letter-variants, the three distinct data sources, and the critical vocalization contrast ("Input is diacritic-insensitive; output is not"), which are essential behavioral details beyond what any schema could convey.

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?

The description is detailed but well-organized, with the primary statement first and supporting details in a scannable list. It avoids redundancy, though the list of letter variants (ا/أ/إ/آ, ي/ى, ه/ة) could be condensed without loss.

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?

The description fully equips the agent by explaining the three result sources, the shape of verb entries (tense-availability flags in `extra`), and the vocalization behavior. Since an output schema exists, the description doesn't need to detail the return structure further; it covers input, processing, and output expectations.

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

Parameters5/5

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

The schema has zero description for the `root` parameter, but the description compensates fully with concrete examples of accepted forms ("كتب", "ك ت ب", "ك-ت-ب", with diacritics) and explains the normalization behavior. This gives the agent complete understanding of what the parameter accepts.

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 description opens with "Look up an Arabic root and return all dictionary entries under it," which names a specific verb and resource. It further distinguishes from siblings by clarifying root-based lookup versus word-based lookup, making the purpose unambiguous.

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 provides a clear trigger: "Use this when the user has already identified the root" and a secondary case: "or when you want to see all sibling words for a lemma." However, it does not explicitly mention alternatives like lookup_word or search_meaning, so it lacks explicit when-not-to-use guidance.

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

lookup_wordA

Look up a surface Arabic word (any inflected form or lemma).

Returns matching entries, each labelled with its root — pivot to lookup_root if you want all sibling words. Matching is case- and diacritic-insensitive. Good when the user gives a word but not the root.

ParametersJSON Schema
NameRequiredDescriptionDefault
wordYes
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that matching is case- and diacritic-insensitive and that results are labeled with roots. It implies a read-only operation but does not mention pagination, error handling, or rate limits—though these are less critical for a simple lookup and an output schema is present.

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 sentences, front-loaded with the primary purpose. Every sentence adds value: purpose, matching behavior, and usage guidance. No redundant phrasing.

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?

The tool is simple; the description covers purpose, matching nuances, and an alternative tool. The presence of an output schema means return values are already defined. It lacks explicit notes on no-match behavior, but this is a minor gap given the output schema.

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 0%, so the description must compensate. It clarifies 'word' as a surface form or lemma, but does not explain the 'limit' parameter beyond its default value. This partial coverage earns a mid-range score.

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 description clearly states the tool's action: 'Look up a surface Arabic word (any inflected form or lemma).' It distinguishes from siblings by mentioning that lookup_root is for root-based searches and explicitly notes this tool is 'Good when the user gives a word but not the root.'

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?

Provides explicit guidance: use when the user supplies a word but not the root, and pivot to lookup_root when sibling words are desired. The mention of lookup_root as an alternative is a clear when-not condition, though search_meaning is not explicitly excluded.

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

search_meaningA

Full-text search over dictionary meanings.

Use when the user asks "what's the Arabic root for X?" or gives a concept in English or Arabic. lang="en" searches English (Lane) glosses; lang="ar" searches Arabic (arramooz) definitions. Results are ranked by relevance and each carries its root, so you can call lookup_root on the best match for full context.

ParametersJSON Schema
NameRequiredDescriptionDefault
langNoen
limitNo
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

Although no annotations exist, the description discloses useful behavioral traits: results are 'ranked by relevance' and each carries its root, enabling chaining to `lookup_root`. It also clarifies search corpora per language. It doesn't explicitly state read-only nature, but for a search tool this is implied; still, with no annotations, full burden rests on the description, which meets most expectations but omits edge-case behavior like limits or error handling.

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 three sentences: a one-line purpose, a usage condition, and language/search behavior. It is front-loaded with the core action, and every sentence contributes to understanding selection or invocation. No unnecessary detail.

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?

Given the output schema exists and the tool is a straightforward search with one required parameter, the description covers usage, language options, result ranking, and the appropriate next step. It lacks mention of `limit`, but that's a schema default, and no other contextual gaps are apparent. The description is comprehensive for a search tool.

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?

With 0% schema description coverage, the description compensates by explaining `query` (concept in English or Arabic) and `lang` (English Lane glosses vs Arabic arramooz definitions). It does not elaborate on `limit`, but the parameter is self-explanatory and has a default in the schema. The description adds meaningful context for the two core parameters.

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 description opens with 'Full-text search over dictionary meanings,' which clearly identifies the tool's function and resource. It distinguishes from sibling lookup tools by focusing on searching meanings, not exact-word lookup, and references calling `lookup_root` as a follow-up. This provides a specific verb and resource scope.

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?

It explicitly states when to use: 'Use when the user asks "what's the Arabic root for X?" or gives a concept in English or Arabic.' It also explains the `lang` parameter's role in choosing between English glosses and Arabic definitions, and even directs follow-up to `lookup_root`. This is clear contextual guidance without needing to mention exclusions.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedlookup_root
    • First observedlookup_word
    • First observedsearch_meaning
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct access path: root lookup, surface word lookup, and meaning search. The descriptions explicitly differentiate when to use each, so there is no ambiguity.

Naming Consistency5/5

All tools follow a clear verb_noun pattern: lookup_root, lookup_word, search_meaning. The pattern is consistent and predictable.

Tool Count5/5

Three tools is well-scoped for a dictionary server. Each tool covers a necessary and non-overlapping function, and the count is within the typical 3-15 range.

Completeness5/5

The tool set covers the full spectrum of dictionary queries: root lookup, word lookup, and semantic search. This provides comprehensive coverage for the domain with no obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/arnizamani/arabic-dict-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server