Using phoneme search: what the feature is for

Urimalsaem (Open Korean Dictionary) phoneme search searches the Urimalsaem dictionary by initial consonant, vowel, and final consonant (jamo) conditions. This document answers the question, "So where do I use it?" It explains real use cases, split between people using it directly and AI agents using it through the MCP tool (search_dict).

Why AI language models need this tool

If you ask an AI language model, "List every verb that ends in a ㅎ final consonant," it gets a few right, but it leaves some out or makes some up. There are two reasons.

1. Language models cannot handle characters at the jamo level. A model works with whole characters, so it cannot reliably check a condition like "the final consonant is ㅎ". It often gets even "a word that has a final consonant" wrong.
2. Language models cannot list items exhaustively. They recall from memory, so they cannot satisfy a request for "all of them", and they fill the gaps with plausible-sounding words.

search_dict covers both weaknesses precisely. The server does the jamo checks, and the search over the whole Urimalsaem (about 1.13 million entries) guarantees "all of them". The agent builds its results only from headwords that actually exist in the dictionary, so there is no room for invented words to slip in.

Use case 1: Korean-language research and education, building word lists from phonological conditions

Research on irregular conjugation is a typical example. The ㄷ-irregular pattern (걷다 → 걸어) occurs only in predicates whose stem ends in a ㄷ final consonant, so collecting all the candidates is the first step in research and in making teaching materials.

{ "name": "search_dict",
  "arguments": { "pattern": "*{//ㄷ}다", "pos": ["용언"], "std_only": true } }

You can make lists like these in the same way.

If you follow up with the agent, "Make this list, and verify with the conjugated forms whether each word is really irregular," it can go all the way to splitting regular from irregular using the conjugated-form (conju) information in the search_dict result, in one go.

Use case 2: Writing and naming, finding words by ending or beginning sounds

Use it to match end rhyme in poems, lyrics, and copy, or to name products and services.

• "Words ending in '-아지'" → suffix match 아지 → 송아지, 망아지, 강아지 (suffixed derived words that mean small things or young animals gather at a glance)
• "Pet names ending in '-둥이'" → suffix match 둥이 → 막둥이, 쌍둥이, 귀염둥이
• "Two-character words with no final consonant, for a soft feel" → {//-}{//-} + part of speech: noun → all two-syllable nouns without a final consonant

{ "name": "search_dict",
  "arguments": { "pattern": "둥이", "anchor": "suffix", "pos": ["명사"], "with_definition": true } }

When you use it with an agent, the model takes over follow-up judgments such as "Pick only the ones with a positive feel." The work is divided: the search collects all the candidates, and the model does the choosing.

Use case 3: Word games and quizzes, finding words by initial consonants

For an initial-consonant quiz (words starting with "ㄱㅅ"?), put an initial-consonant condition on each syllable.

{ "name": "search_dict",
  "arguments": { "pattern": "{ㄱ}{ㅅ}", "pos": ["명사"], "std_only": true, "count_only": true } }

• {ㄱ}{ㅅ} full match → two-character words whose initial consonants are ㄱ and ㅅ (가수, 감사, 군수 ...)
• Word-chain game strategy: "Is there a standard word that starts with '름'?" → prefix match 름 + count_only
• Making Korean word puzzles (Wordle-style): build a candidate pool of "three-character nouns without a final consonant"

A good flow is to use count_only first to see the size, and then get the list. A broad pattern can have tens of thousands of candidates.

Use case 4: Language data and dictionary work, extracting words by condition

These are cases for developers and researchers working with Korean NLP data or dictionaries.

• Extracting words subject to pronunciation changes: Phonological phenomena such as tensification and nasalization occur in specific final consonant + initial consonant sequences. Pull the target words by final consonant condition to make a review list for a pronunciation dictionary or TTS data.
• Dictionary auditing: Check in reverse whether "all entries that meet this condition are in the dictionary." In fact, this feature started out of Bareun's own dictionary auditing work (the repeated task of pulling every predicate with the same stem shape).
• Comparing against non-standard words: A default search returns dialect, North Korean, and non-standard forms together, with standard-word information (stdWord) attached. By comparing against the result with std_only on, you can count "how many non-standard forms there are under this condition."

How to read the results: the evidence is kept

Besides the list, a search_dict response also includes the following. An agent can quote them directly when it shows the basis for its answer.

Frequently asked questions

Q. When does an AI agent use this tool?

A. When a request like "words that end/start with ~", "words whose final consonant/initial consonant/vowel is ~", or "all words with ~ condition" comes in, the agent picks and calls search_dict. These conditions are spelled out in the tool description, so it is chosen without separate instructions, but saying "look it up in Urimalsaem" makes it more certain.

Q. How is this different from a language model just answering?

A. A model's memory leaves things out and makes things up. This tool actually scans the whole Urimalsaem, so the results are backed by the dictionary, and even the total count (totalMatched) is accurate. The difference is largest for requests that include "all" or "how many".

Q. The search results include odd words.

A. Urimalsaem includes dialect words, North Korean words, archaic words, and non-standard forms. To see only standard words, turn on std_only. You can also tell them apart by the dialect/North Korean/non-standard markers in the result and by the standard-word information (stdWord).

Q. How long does one search take?

A. It scans everything without an index, so it takes a few hundred milliseconds per search. That is enough for interactive and research use, and for a broad pattern it is best to check the size first with count_only.