Pronounce / pronounce-mcp
This server lets you look up and explore canonical pronunciations of developer jargon, tech acronyms, and project names from a curated dictionary of 1,880+ entries.
Look up a word's pronunciation (
pronounce): Get the IPA transcription, a human-friendly respelling, a playable MP3 audio URL, alternate readings (e.g., for contested words like GIF or SQL), source citations (e.g., creator interviews, official docs), confidence level, and editorial notes for any developer-related term likekubectl,nginx,Pydantic,JSON,Knative, etc.Search the dictionary (
search_pronunciations): Find entries by partial word match or category (e.g., search for "postgres" or "acronym") when you don't know the exact spelling; returns matching entries with their word, slug, category, and confidence rating.Browse/list dictionary entries (
list_pronunciations): List dictionary entries optionally filtered by category (e.g.,product,project,cli-tool,cs-term,acronym,person) and/or a result limit, allowing you to explore the full dictionary in a focused way.
π Try it in 30 seconds
git clone https://github.com/anzy-renlab-ai/pronounce.git
cd pronounce && ./install.sh
say-it kubectl
That's it. Now try say-it GIF, say-it nginx, say-it Pydantic, say-it --why JSON, or say-it quiz for a 10-question challenge. Linux users: install espeak-ng (sudo apt install espeak-ng) and the CLI just works. Windows: same CLI under WSL or git-bash + PowerShell. Or skip install and use the browser at pronounce.renlab.ai.
β If
say-it kubectlsaves you one cringey standup moment β star the repo. It nudges more devs to contribute their favorite mispronounced project name.
Related MCP server: wordorb
π The developer pronunciation scoreboard
1,903 entries β 1,283 carry a citable source β 108 settled by the creator themselves, 175 the community still argues about. The famous ones:
β Settled β the creator said so
Word | It'sβ¦ | β¦not | Settled by |
"jif" | "ghif" (hard-G speech cue) | Steve Wilhite (creator), NYT 2013 | |
"engine X" | "n-jinx" | NGINX official | |
"yam-ul" | "yammel" | yaml.org | |
"guh-NEW" (hard g) | "noo" | GNU Project | |
"lay-tek" | "lay-teks" | Lamport / LaTeX project | |
rhymes with "knoll" | "tom-el" | Tom Preston-Werner (creator) | |
"tickle" | "T-C-L" | John Ousterhout (creator) | |
"auk" (like the bird) | "A-W-K" | Aho / Weinberger / Kernighan |
βοΈ Still contested β both readings are in active use
Word | Camp A | Camp B |
"koob-control" | "cube-cuddle" | |
"sequel" | "S-Q-L" | |
"JAY-son" | "JEE-son" | |
"gooey" | "G-U-I" | |
"jot" (per RFC 7519) | "J-W-T" |
Every cell has IPA and audio; 1,283 also carry a citable source. Browse all 1,903 entries β
Disagree with one? That's the whole point β open a PR with your reading and a source. The argument is the dataset.
What you're actually getting
1,903 entries β 1,283 carry a citable source. Confidence-tagged (
creator-clarified/community-consensus/contested), each with a citable URL where one exists (we'd rather leave it blank than fabricate one). Wilhite said GIF is "jif" at the 2013 Webby Awards. Crockford says JSON is "JAY-son" (RailsConf 2009). RFC 7519 says JWT is "jot". The dictionary cites them.Multi-reading audio. For words where the debate is real β GIF, SQL, GUI, char, regex β the CLI chains the alternates after the primary with a spoken "or:" so you hear the debate without staring at the terminal.
--soloskips the tail once you've internalized it.One Bash CLI, no npm runtime. No sudo, no framework bootstrap, no surprises. It detects macOS
say, Linuxespeak-ng/espeak, or Windows PowerShellSystem.Speech. The repo also ships a Claude Code skill and an MCP server so your AI answers "how do you pronounce X?" with audio, not a phonetic guess.A docs-native GitHub Action. Scan Markdown changed by a pull request and emit a sourced pronunciation glossary in the job summary β no API key, dependency install, or network request.
Canonical website audio. The site plays each committed canonical MP3 first and uses Web Speech only as a fallback if playback fails.
$ say-it --why JSON
word JSON
ipa /ΛdΚeΙͺsΙn/
respelling_us jay son
confidence contested
source Wikipedia Β§ Pronunciation
url https://en.wikipedia.org/wiki/JSON#PronunciationWhy not just Google?
Because Google gives you 47 Reddit arguments and a YouTube clip you have to unmute. IPA gives you /ΛkuΛb kΙnΛtroΚl/ β a reference, not a teacher.
You don't need a phonetic transcription. You need to hear the word. Twice. Maybe three times. Done.
say-it ships a community-maintained dictionary of how engineers actually say the names that trip everyone up β and feeds the intended respelling to your OS's text-to-speech engine, so kubectl comes out as koob-control, not whatever your computer guessed from the letters.
Famous moments
Some pronunciations aren't opinions β the creators settled them. The dictionary cites every one:
Word | Reading | Source |
| "jif" (creator says so) | |
| "jay-son" | |
| "g-noo" (hard G, one syllable) | |
| "LIN-ux" (short i, schwa) | |
| "lay-tek" (or "lah-tek") | |
| "JANG-go" (silent D) | |
| "view" (one syllable) | |
| "veet" (French for quick) | |
| "KAY-native" (the K is voiced) | |
| "et-cee-dee" (et-cetera-distributed) |
Run say-it --why <word> to see the citation when an entry has a source_url; unsourced entries are left blank rather than given a fabricated URL.
Install
brew install anzy-renlab-ai/tap/say-it # Homebrew on macOSOr the "Try it in 30 seconds" block above. ./install.sh drops:
the CLI at
~/.local/bin/say-it,the pronunciation dictionary at
~/.local/share/say-it/pronunciations.tsv,if you use Claude Code, a
pronounce-wordskill at~/.claude/skills/pronounce-word/so any "how do you say X?" prompt to your AI gets answered with audio instead of IPA,the same skill into
~/.agents/skills/(Codex CLI) and~/.kiro/skills/(Kiro) when those dirs exist β it's the cross-tool Agent Skills standard.
Make sure ~/.local/bin is on your $PATH. Linux also works β install espeak-ng (sudo apt install espeak-ng / brew install espeak-ng). Windows: WSL or git-bash + PowerShell. Or skip install entirely with the browser version at pronounce.renlab.ai.
Usage
say-it kubectl # primary Γ 3, then "or: <alt>" for each alternate
say-it --solo kubectl # primary only β silence the "or:" tail
say-it --alt GIF # focus on the first alternate
say-it --alt 2 GUI # focus on the Nth alternate (1-indexed)
say-it --all SQL # primary AND every alternate, each repeated
say-it --no-dict kubectl # bypass the dictionary entirely
say-it --why JSON # show IPA, source URL, category, confidence
say-it list # every word in the dictionary
say-it search redis # grep the dictionary (case-insensitive)
say-it -n 5 Pydantic # 5 repetitions instead of 3
say-it -r 110 Knative # slower (110 wpm; default is 130)
say-it -o /tmp/word.aiff Postgres # save to file instead of playing
say-it --list # all macOS voicesThe default macOS voice is Samantha (General American); -v <voice> selects another macOS voice. Linux and Windows use their detected backend's English voice. The dictionary is GenAm-only, by design.
Claude Code integration
Install the cross-tool Agent Skill directly with GitHub CLI:
gh skill install anzy-renlab-ai/pronounce pronounce-wordYou: kubectl ζδΉθ―»οΌ
Claude: π (plays "koob-control" three times)
/ΛkuΛb kΙnΛtroΚl/ β "KOOB-control". Kelsey Hightower says it
this way (KubeCon talk). "Cube-cuddle" is an alternate β
try `say-it --alt kubectl` to hear it.Once installed, the pronounce-word skill auto-triggers on:
X ζδΉθ―»/X ζδΉει³/θ―»δΈδΈ Xhow do you pronounce X/pronounce X/how do you say X
Your AI replies with sound, not just a phonetic guess. Skill file: skills/pronounce-word/SKILL.md.
Not on Claude? Same skill drops into Codex CLI (codex plugin marketplace add anzy-renlab-ai/pronounce) and Kiro (~/.kiro/skills/), and the MCP server covers Claude Desktop, Cursor, Continue, Zed, Cline & friends β full matrix in integrations/.
GitHub Action β pronunciation guides for docs
Add a pronunciation glossary to every documentation pull request:
- uses: actions/checkout@v7.0.1
with:
fetch-depth: 0
- id: pronounce
uses: anzy-renlab-ai/pronounce@v2.28.1Pronounce Docs scans changed Markdown/MDX and writes a table containing each
matched term, its IPA, plain-English respelling, audio page, and creator or
official source where available. It runs locally from the repository snapshot:
no token, API key, telemetry, package install, or network request. See the
complete setup, inputs, and outputs.
VS Code extension

Hover over any tech word in any file β see the IPA, hear the pronunciation. Same 1,903-entry dictionary as the CLI, JSON-bundled at build (zero runtime parse cost).
# Cursor / VSCodium / Zed / Gitpod / Theia / code-server (Open VSX)
code --install-extension sayit.pronounce
# or the listing: https://open-vsx.org/extension/sayit/pronounceNow live on Microsoft Marketplace too: ext install sayit.pronounce in VS Code. See marketplace listing.
Hover over
kubectl,YAML,Ghostty,wagmiβ¦ β tooltip with IPA + π Play + β Star link.ββ§' β speak selection.
Status bar
π sayitβ click to speak the current selection.Welcome walkthrough β 4-step onboarding on first install.
Pronounce: Search dictionaryβ¦β fuzzy-find all 1,903 entries.
Source: integrations/vscode/. Cross-platform as of v0.3 β macOS say, Linux espeak-ng, Windows PowerShell.
Chrome / Edge / Brave extension
Click any tech word on any webpage β popup with IPA + audio. Same 1,903-entry dictionary. The extension speaks through Web Speech; pronounce.renlab.ai plays the committed MP3 corpus first and reserves Web Speech for fallback. Sideload only for now (not yet on Chrome Web Store).
Download pronounce-chrome-0.3.1.zip β unzip β chrome://extensions/ β Developer mode β Load unpacked.
Source: integrations/chrome/.
How the dictionary works
data/pronunciations.tsv is the single source of truth β tab-separated, 1,903 entries, covering:
Cloud / DevOps:
kubectl,nginx,Kubernetes,helm,Istio,Envoy,Prometheus,Grafana,Terraform,Argo,Knative,etcd,containerd,runc,Podman, ...Languages / Frameworks:
Django,Vue,Vite,Pydantic,Bun,Deno,Hugo,Hono,Caddy,Svelte,Astro,Pinia, ...Databases:
PostgreSQL,Postgres,SQLite,MySQL,MongoDB,Cassandra,Redis,Ceph,ScyllaDB,ClickHouse,DuckDB, ...CS jargon / acronyms:
GIF,JSON,SQL,GUI,GNU,char,regex,sudo,tmux,chmod,WYSIWYG,ASCII,enum,NaN,SaaS,PaaS, ...Distros / tools:
Linux,Debian,Ubuntu,Arch,Nix,LaTeX,TeX,emacs,zsh, ...
Each entry has 10 columns: word | ipa | respelling_us | alt_ipa | alt_respelling_us | source_url | source_label | category | confidence | notes. respelling_us is plain English-like input passed to the detected OS TTS backend, so the intended reading is spoken instead of asking the engine to guess from the project name.
Local override: drop a ~/.config/say-it/pronunciations.local.tsv and it takes precedence.
What works today
β macOS β built-in
say.β Linux β
espeak-ng(preferred) orespeak.β Windows β PowerShell
System.Speechfrom the same Bash CLI under Git Bash/MSYS2/Cygwin.β 1,903 entries; 1,283 carry a citable source β the rest are confidence-tagged, no fabricated citations.
β Audible multi-reading awareness β contested words audibly chain alternates with "or:".
β
--alt [N],--all,--solo,--why,--json,--md,--no-dict,list,search,quiz,repl,stream,doctor,export,benchmark,badge,cheatsheet.β Claude Code skill + MCP server for AI-side pronunciation questions.
β GitHub Action β sourced pronunciation glossaries for Markdown pull requests.
β Browser PWA β installable, offline-capable, instant search, voice-mic search, interactive quiz.
β Editor integrations β Raycast, Alfred, VS Code, Cursor, Codex, Kiro, Continue.
β π Live site β pronounce.renlab.ai (1,903 entries browsable with audio; 1,283 sourced entries) + /zh (Chinese landing).
What's coming
See DESIGN.md for the architecture.
βοΈ Cloud TTS (opt-in ElevenLabs / OpenAI) for the names native TTS still mangles.
π Anki export for vocabulary drills.
π Light theme on the v2 homepage (already shipped on word/SEO pages).
Contributing
Two things we want most:
Pronunciation entries. Open a PR adding a row to
data/pronunciations.tsv. Required columns:word,ipa,respelling_us. Highly preferred:source_url(creator interview, conf talk, official FAQ β anything verifiable). Contested readings are welcome; put the rival inalt_*columns and we'll wire--altthrough.Backend quality. macOS (
say) is the gold standard; the Linux (espeak-ng) and Windows (PowerShell) backends ship but are best-effort β help us close the gap. SeeDESIGN.mdΒ§Backends.
Keep it tiny. Keep it dep-free where possible. Keep the defaults opinionated (3 reps, GenAm, Samantha voice).
β Support β start with a star
The dictionary is free and MIT. The single highest-leverage thing you can do is star the repo β it's the signal that pulls in more contributors, more PRs, more creator-clarified entries.
β Star on GitHub β β one click, no signup, biggest effect.
Optional, if it's saved you real standup pain:
β Coffee on Ko-fi β pays for one new entry per cup.
π Sponsor on GitHub β recurring tier (pending Sponsors approval).
Dollars cover hosting (Vercel/Cloudflare/Open VSX), domain renewals, MiniMax narration credits for promo videos, and time to track down creator citations for new entries.
Contributors
Every entry, source upgrade, and skill fix counts. Open a PR β your face shows up here.
License
MIT β see LICENSE.
IPA is a reference. Audio is a teacher.
Available Tools
3 toolslist_pronunciationsA
List dictionary entries, optionally filtered by category.
Categories include: product, project, cli-tool, tool, cs-term,
acronym, abbreviation, person. The dictionary holds well over 1500
entries and grows continuously, so the unfiltered list is large β
pass category and/or limit to keep the result focused.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses that the dictionary is large and growing, and that unfiltered lists are big. This adds some behavioral context, but could mention more about response structure or performance.
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?
Concise two-sentence description with clear bullet-like list of categories. Front-loaded with purpose. Could be slightly more structured but is efficient.
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 output schema exists (but not shown), description covers param guidance. Lacks mention of authentication or pagination behavior beyond limit, but is sufficient for a list tool.
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 has 0% description coverage, but the description explains the purpose of category (listing possible values) and limit (keeping results focused), compensating for the lack of param descriptions. However, missing details like default limit value are already in schema.
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 it lists dictionary entries with optional category filtering. It distinguishes from siblings implicitly (list vs search), but does not explicitly contrast with 'search_pronunciations'.
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?
Provides advice to use category and limit for focused results, but does not specify when to use this tool over the sibling 'search_pronunciations' tool, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pronounceA
Look up the canonical pronunciation of a developer-related word.
Returns the IPA, a respelling that approximates how engineers actually
say the word, a playable MP3 audio_url, optional alternate readings,
the source citation when available, and editorial notes. Use this for project names like
kubectl, nginx, GIF, JSON, Pydantic, Knative, programmer
jargon, and tech acronyms. Returns an error dict if the word is not
in the dictionary; for general English vocabulary, fall back to your
own knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the return content (IPA, respelling, audio_url, alternate readings, source citation, editorial notes) and error behavior (error dict if word not found). It does not mention authentication or rate limits, but as a read-only lookup, this is acceptable.
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 concise with four sentences, each adding value. It is front-loaded with the main purpose, followed by return details, usage scope, and error handling. No superfluous information.
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 and no output schema, the description covers all essential aspects: purpose, return fields, error case, and scope limitations. It is sufficiently complete for an agent to use the tool correctly.
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?
The only parameter 'word' is described implicitly through examples and scope (developer-related word). Schema coverage is 0%, so the description compensates by providing context that the word should be a tech term or acronym, which adds meaning beyond the schema.
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 looks up canonical pronunciations for developer-related words, with specific examples (kubectl, nginx, GIF, etc.). It distinguishes from siblings like list_pronunciations and search_pronunciations by focusing on a single word lookup.
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 explicitly says when to use the tool ('Use this for project names like...') and when not to ('for general English vocabulary, fall back to your own knowledge'). However, it does not compare directly to sibling tools, which could provide more precise guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_pronunciationsA
Search the dictionary by partial word or category match.
Matches substrings against the entry's word and category only β
the search index (/api/words.json) carries no notes or source text, so
a query like "Kelsey" will NOT surface kubectl. To read an entry's
notes, look it up with pronounce.
Returns a list of matching entries with word, slug, category,
and confidence. Use this when the exact spelling is unknown or
when browsing entries by category.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 delivers: it explains the search index limitation, the negative example with 'Kelsey' and `kubectl`, the fields returned, and the fact that notes are not searchable. This is far more than a generic 'Search' claim.
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 front-loaded with the core purpose, then adds a necessary limitation, a return-shape summary, and a usage guideline. Every sentence contributes something non-redundant, and the negative example earns its place by preventing a likely misquery.
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 two-parameter search tool with an output schema, the description supplies the matching semantics, the scope limitation, the returned fields, and when to choose the tool. Nothing essential for correct invocation is missing, and the output schema can handle the precise return structure.
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 0%, so the description must compensate. It clearly defines the `query` semantics as a substring match against `word` and `category`. The `limit` parameter is not described, though its default is in the schema and its meaning is self-evident from the name.
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 opens with a specific verb and resource: 'Search the dictionary by partial word or category match.' It further clarifies the matching scope and explicitly contrasts itself with the exact-lookup behavior of `pronounce`, so an agent can distinguish it from siblings.
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?
It explicitly states when to use this tool ('when the exact spelling is unknown or when browsing entries by category') and when to use an alternative ('To read an entry's notes, look it up with `pronounce`'). This gives clear decision guidance relative to the sibling tools.
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 tool update
v2.28.1- Added
search_pronunciations
1 tool update
v2.23.0- Removed
search_pronunciations
3 tool updates
v0.1.1- First observed
list_pronunciations - First observed
pronounce - First observed
search_pronunciations
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: pronounce for exact word lookup, search_pronunciations for partial/category matching, and list_pronunciations for browsing with filters. The only slight overlap between search and list is clarified by their descriptions.
Two tools follow a verb_noun pattern (search_pronunciations, list_pronunciations), while the core tool is just the bare verb pronounce. This is a minor deviation, but the overall naming is predictable and readable.
Three tools is well-scoped for a pronunciation dictionary: lookup, search, and list cover the essential interaction modes without redundancy. Each tool earns its place.
For the stated domain of looking up developer-related pronunciations, the surfaces are complete: exact lookup, discovery by partial match, and category-based browsing. There are no obvious dead ends or missing operations.
Maintenance
Related MCP Connectors
Latest versions, LTS windows, and EOL dates for 300+ products. Fresh ground truth for stale models.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation forβ¦
Read-only Pattern-Assist corpus for aspiring software engineers: grounded dev patterns with sources.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenancePhonetic analysis engine that gives LLMs accurate rhyme detection, stress scanning, meter identification, and syllable counting backed by the full CMU Pronouncing Dictionary.5MIT
- FlicenseNot gradedqualityDmaintenanceWord Orb is a language enrichment MCP server. 50,000+ words with IPA, definitions, etymology, translations in 47 languages with native script, gender equity guidance, and AI identity ethics. 3ms edge response. Tools: word_enrich, word_ethics, agent_speak. URL: https://mcp.wordorb.ai/mcp-
- AlicenseNot gradedqualityDmaintenanceVocabulary intelligence MCP server β 162K words, 47 languages, definitions, IPA pronunciation, etymology, translations, and daily lessons. 19 tools for AI agents.7 npm1MIT
- AlicenseNot gradedqualityAmaintenanceMultilingual name romanization lookup across Chinese, Japanese, Korean, Arabic, Vietnamese, and more. Resolves whether two name spellings refer to the same person β Chan/Chen/ι³/ι, Hsu/Xu, Chou/Zhou β across Pinyin, Wade-Giles, Cantonese, Hokkien, and other romanization systems.MIT