This server provides MCP tools for bidirectional transliteration between Latin-script Javanese and Aksara Jawa (Hanacaraka).
to_aksara: Convert Latin-script Javanese text to Aksara Jawa, with optional preservation of spaces (spaces) and use of standalone vowel letters (explicit_vowels).
from_aksara: Decode Aksara Jawa text back to Latin script, handling murda consonants, retroflex letters (ṭ, ḍ), cakra, pengkal, and standalone vowel letters.
Useful for reading manuscript OCR output, transliterating user input, and working with Javanese script in both directions without guessing Unicode codepoints.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aksara-mcp convert 'sugeng enjing' to Aksara Jawa"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Moved. This GitHub copy is an archive. Use the Forgejo repository.
Canonical repository: https://git.simonharms.com/thesimonharms/aksara-mcp
MCP server that gives AI agents bidirectional transliteration between Latin-script Javanese and Aksara Jawa (Hanacaraka), powered by aksara-ts.
lamun sira nginguk ucing → ꦭꦩꦸꦤ꧀ꦱꦶꦫꦔꦶꦔꦸꦏꦸꦕꦶꦁ
ꦲꦤꦕꦫꦏ → hanacarakaAksara Jawa is essentially absent from LLM training data. This server lets agents read manuscript OCR output, transliterate user input, and work with Javanese script in both directions without guessing at rare Unicode codepoints.
Tool | Direction | Description |
| Latin → Aksara | Convert Latin-script Javanese to Hanacaraka |
| Aksara → Latin | Decode Aksara Jawa back to Latin script |
to_aksaraParameter | Type | Default | Description |
|
| — | Latin-script Javanese text |
|
|
| Preserve spaces in the output |
|
|
| Use standalone vowel letters (ꦄ ꦆ ꦈ ꦌ ꦎ) for vowels without a preceding consonant |
from_aksaraParameter | Type | Description |
|
| Aksara Jawa text to decode |
Decoding handles murda consonants, retroflex letters (ṭ, ḍ), cakra (medial r), pengkal (medial y), and standalone vowel letters.
Related MCP server: timemap-mcp
npm install aksara-mcpOr clone and build locally:
git clone https://github.com/thesimonharms/aksara-mcp.git
cd aksara-mcp
npm install
npm run buildRequires Node.js 18+.
{
"mcpServers": {
"aksara": {
"command": "node",
"args": ["/absolute/path/to/aksara-mcp/dist/index.js"]
}
}
}If installed globally or via npx:
{
"mcpServers": {
"aksara": {
"command": "npx",
"args": ["aksara-mcp"]
}
}
}Latin → Aksara
{ "text": "hanacaraka" }→ ꦲꦤꦕꦫꦏ
{ "text": "aji saka", "spaces": true }→ ꦲꦗꦶ ꦱꦏ
{ "text": "aksara", "explicit_vowels": true }→ ꦄꦏ꧀ꦱꦫ
Aksara → Latin
{ "text": "ꦲꦤꦕꦫꦏ" }→ hanacaraka
{ "text": "ꦧꦸꦟ꧀ꦝꦼꦭ꧀" }→ bunḍel
npm run build # bundle server to dist/
npm start # run on stdio
npm test # build + run cobasaja testsTests live in tests/ and use cobasaja to spawn the server over stdio and assert tool behaviour end-to-end.
Inherited from aksara-ts:
ꦲ ambiguity — the glyph is both consonant h and the carrier for standalone vowels. from_aksara on ꦲꦗꦶ returns haji, not aji. Use explicit_vowels: true when encoding if disambiguation matters.
Spaces — Aksara Jawa traditionally omits word boundaries. Pass spaces: true to to_aksara if you need spaces preserved for round-tripping.
MIT © Simon Harms
Convert Aksara Jawa (Hanacaraka script) to Latin-script Javanese. Handles murda consonants, retroflex letters, cakra, pengkal, and standalone vowel letters.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Aksara Jawa text to decode to Latin script |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the conversion and special cases handled, but does not disclose error handling, input validation, or side effects. For a conversion tool, this is adequate but not fully transparent.
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 two sentences, front-loaded with the primary action, and contains no redundant information. Every word adds value.
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?
Given the simple input schema (one string parameter, no output schema), the description provides sufficient context: it explains the transformation and lists supported script features. It does not discuss return format or edge cases, but overall is complete enough for a straightforward conversion.
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% (parameter 'text' described as 'Aksara Jawa text to decode to Latin script'). The description adds value beyond the schema by listing specific script features handled, enhancing the agent's understanding of valid inputs.
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 clearly states the tool converts Aksara Jawa to Latin-script Javanese, specifying the input and output scripts. It lists specific features handled (murda, retroflex, cakra, etc.), distinguishing it from the sibling tool 'to_aksara' which performs the reverse operation.
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?
The description implies when to use this tool (to decode Aksara Jawa to Latin) and the sibling tool name provides context, but it does not explicitly state when not to use it or compare to alternatives. The purpose is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert Latin-script Javanese text to Aksara Jawa (Hanacaraka script). Supports optional space preservation and explicit standalone vowel letters.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Latin-script Javanese text to transliterate | |
| spaces | No | Preserve spaces in the output (default: false) | |
| explicit_vowels | No | Use standalone vowel letters (ꦄ ꦆ ꦈ ꦌ ꦎ) for vowels without a preceding consonant (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions optional space preservation and explicit vowels, which adds behavioral context. However, it does not disclose potential limitations (e.g., unsupported characters, error handling) or the exact output format beyond being Aksara Jawa.
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 extremely concise: one sentence stating the core function and a second sentence listing the optional features. No wasted words, front-loaded with the main action.
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 simple conversion tool, the description covers the basics but lacks information about return value format, error conditions, or handling of invalid input. Given no output schema and no annotations, more detail would be helpful for reliable usage.
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 baseline 3. The description adds value by explaining the purpose of the two boolean parameters ('space preservation' and 'explicit standalone vowel letters') in context, helping the agent understand their effect beyond the schema's dry descriptions.
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?
Description clearly states the tool converts Latin-script Javanese text to Aksara Jawa (Hanacaraka script). It specifies the exact resource and action, distinguishing it from the sibling tool 'from_aksara' which does the reverse.
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?
Usage is implied by the description: use this tool to transliterate to Aksara Jawa. The sibling 'from_aksara' provides the alternative for the reverse direction. No explicit when-not or prerequisites, but the context is straightforward.
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.
v1.0.0from_aksarato_aksaraScored across 2 tools
The two tools have clearly opposite purposes: one converts from Aksara to Latin, the other from Latin to Aksara. There is no overlap or ambiguity.
Both tool names follow a consistent 'direction_aksara' pattern using snake_case, making them predictable and easy to understand.
With exactly 2 tools (one for each conversion direction), the server is perfectly scoped for its purpose—no more, no less.
The toolset covers the entire bidirectional conversion between Aksara Jawa and Latin script, with no missing operations for its defined domain.
Machine-readable utilities and datasets for AI agents.
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
