Click on "Install 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., "@datamuse-mcp Find synonyms for happy."
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.
MCP server for the Datamuse API (word search, rhymes, synonyms, and more).
This project is open source, free to use, and licensed under MIT.
datamuse-mcp is a local stdio MCP server that wraps Datamuse endpoints into validated MCP tools.
It is designed for practical word-finding use cases in assistants and clients that support MCP.
Related MCP server: Similar Words MCP Server
This server provides simple MCP tools to:
find synonyms, antonyms, and rhymes;
run autocomplete;
fetch lexical details (definitions, POS, syllables, pronunciation, frequency);
search by spelling pattern (*, ?) or phonetic similarity.
Node.js >= 18
npm
npm installnpm run devnpm run build
npm start# List tools
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node dist/index.js
# Call a tool
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"find_synonyms","arguments":{"word":"happy"}}}' | node dist/index.js{ "tool": "find_antonyms", "arguments": { "word": "happy", "max": 10 } }
{ "tool": "find_rhymes", "arguments": { "word": "love", "type": "perfect", "max": 20 } }
{ "tool": "find_similar_sounding", "arguments": { "text": "definately", "max": 15 } }
{ "tool": "find_by_pattern", "arguments": { "pattern": "s??r?", "meaning_hint": "celestial", "max": 25 } }
{ "tool": "find_related_words", "arguments": { "word": "music", "relation_type": "triggers", "max": 15 } }
{ "tool": "get_word_info", "arguments": { "word": "serendipity" } }
{ "tool": "autocomplete", "arguments": { "prefix": "astro", "max": 10 } }Add this to claude_desktop_config.json:
{
"mcpServers": {
"datamuse": {
"command": "node",
"args": ["/absolute/path/to/datamuse-mcp/dist/index.js"]
}
}
}find_synonyms
find_antonyms
find_rhymes
find_similar_sounding
find_by_pattern
find_related_words
find_adjectives_for_noun
find_nouns_for_adjective
get_word_info
autocomplete
The server runs over stdio (local usage recommended).
Outbound requests go to https://api.datamuse.com.
A local in-memory cache is used (5-minute TTL), with no disk persistence.
Datamuse may enforce request limits/quotas.
For npm and MCP Registry deployment, see PUBLISHING.md.
See CONTRIBUTING.md.
MIT — see LICENSE.
Get word suggestions for a partial input. Includes intelligent spelling correction and phonetic fallbacks when exact prefix matches aren't found.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum number of suggestions (1-25, default: 10) | |
| prefix | Yes | The partial word to complete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses intelligent spelling correction and phonetic fallbacks beyond basic prefix matching. Could mention case sensitivity or empty prefix behavior, but current disclosure is good for a simple recommendation tool.
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?
Two sentences, main purpose first, then additional features. No redundant words or filler. Highly 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?
Tool is low-complexity with 2 params and no output schema. Description covers core behavior and distinctive features. Could mention default max or ordering of results, but adequate overall.
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 coverage is 100%, so baseline is 3. Description does not add extra meaning to 'prefix' or 'max' beyond the schema. No parameter-specific elaboration.
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?
Clear verb 'Get word suggestions' and resource 'partial input'. Description distinguishes from siblings by mentioning spelling correction and phonetic fallbacks, which are not found in synonym/rhyme tools.
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?
Implied usage from 'for a partial input' but no explicit when-to-use or when-not-to-use. Does not name alternatives from sibling list, although context makes it obvious this is for general completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find adjectives commonly used to describe a noun. Based on Google Books Ngrams data. Example: 'ocean' → deep, blue, vast, pacific.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum number of results (1-50, default: 15) | |
| noun | Yes | The noun to find adjectives for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the data source (Google Ngrams) and implies ranked commonality via the example, but does not disclose whether the tool is read-only, has rate limits, returns sorted results, or any idiosyncrasies. The description is insufficient for a critical mutation tool scenario.
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 exceptionally concise: two sentences and an example. It is front-loaded with the main action ('Find adjectives commonly used to describe a noun'), and every word serves a purpose. The example efficiently demonstrates input and output without wasted text.
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 low-complexity tool with 2 parameters, no output schema, and no annotations, the description provides sufficient context: the data source and an example output format. However, it lacks explicit mention of return structure (e.g., list, array) or potential edge cases (e.g., rare nouns). Still, given the tool's simplicity, it is largely complete enough for an AI agent.
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 coverage is 100% (both parameters have descriptions in the schema). The description adds no extra meaning beyond the schema; it does not elaborate on the 'max' parameter's range or default, nor does it clarify the 'noun' parameter beyond its use. Baseline is 3 as per rubric, since high schema coverage mitigates the lack of parameter details in the description.
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 'Find adjectives commonly used to describe a noun' with a specific verb and resource. It includes a concrete example ('ocean' → deep, blue, vast, pacific) that instantly distinguishes it from sibling tools like find_synonyms or find_nouns_for_adjective, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusion criteria, prerequisites, or compare to siblings. The only contextual hint is 'Based on Google Books Ngrams data,' which vaguely suggests usage for common collocations but lacks clear direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find antonyms (words with opposite meanings) for a given word using WordNet relationships.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum number of results (1-50, default: 10) | |
| word | Yes | The word to find antonyms for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions using WordNet relationships, but fails to disclose return format, error handling, or potential side effects. For a read-only tool, this is minimal.
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 a single, well-formed sentence with no extraneous information. It is concise and front-loaded with the key purpose.
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 tool's simplicity (2 parameters, no output schema), the description is adequate but incomplete. It does not describe the output format or list returned, which an AI agent would need to know for effective use.
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 input schema provides complete descriptions for both parameters (word and max), so the description adds no additional meaning. Baseline score of 3 is appropriate as schema coverage is 100%.
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 finds antonyms (words with opposite meanings) for a given word using WordNet relationships. It distinguishes from sibling tools like find_synonyms and find_rhymes by specifying the opposite meaning relationship.
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?
No explicit guidance on when to use this tool versus alternatives like find_synonyms. The context of siblings implies use when antonyms are needed, but no when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find words matching a spelling pattern with wildcards. Use '' for any number of characters, '?' for exactly one character. Examples: 't??k' matches talk/tank/tick, 'unable' matches unable/unforgettable.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum number of results (1-100, default: 25) | |
| pattern | Yes | Spelling pattern with wildcards (* or ?) | |
| meaning_hint | No | Optional meaning to filter results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description adds wildcard syntax and examples but omits case sensitivity, invalid pattern handling, or output characteristics.
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?
Two efficient sentences with front-loaded purpose; every sentence serves a purpose.
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?
Lacks description of output format or return values; given no output schema, agent needs more context about results.
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 covers all 3 parameters; description adds value by explaining wildcards for pattern and providing examples, though max and meaning_hint lack additional info.
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 it finds words matching a spelling pattern with wildcards, with examples that differentiate it from semantic or rhyming 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?
Implies use for pattern matching; sibling names (synonyms, antonyms, rhymes) provide context, but no explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find nouns commonly described by an adjective. Based on Google Books Ngrams data. Example: 'yellow' → sun, light, fever, pages.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum number of results (1-50, default: 15) | |
| adjective | Yes | The adjective to find nouns for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral disclosure. It mentions data source but omits details like ordering, default max, return format, or case sensitivity. Behavioral expectations are minimally addressed.
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?
Two sentences plus an example—no wasted words information is front-loaded. The example succinctly clarifies expected output format.
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 simple parameters and no output schema, the description is adequate but could be more complete by explaining result ordering, default max, and statistical significance. It misses some context that would help an agent.
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 covers 100% of parameter descriptions. The description adds an example which complements the schema but does not add new meaning. Baseline score of 3 is appropriate.
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 finds nouns commonly described by an adjective, with specific data source and example. It effectively distinguishes from siblings like find_adjectives_for_noun 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?
The description implies usage for finding common collocations but does not explicitly state when to use this tool versus alternatives like find_adjectives_for_noun or other word tools. No exclusions or context-aware guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find words that rhyme with a given word. Supports perfect rhymes and near-rhymes. Useful for poetry, songwriting, and creative writing.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum number of results (1-100, default: 20) | |
| type | No | Type of rhyme: 'perfect' for exact rhymes, 'near' for approximate (default: perfect) | |
| word | Yes | The word to find rhymes for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as data mutations, permissions, or rate limits. It only describes basic functionality.
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 main action, and no unnecessary words. Efficient and clear.
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?
The description lacks information about output format or edge cases. For a simple lookup tool, it is adequate but could be improved with response details.
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?
Input schema has 100% parameter description coverage. The description adds context about rhyme types but does not enhance understanding beyond the schema definitions.
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 finds rhymes for a given word, supporting perfect and near-rhymes. It distinguishes from siblings like find_synonyms and find_antonyms by focusing on rhyming.
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 mentions usefulness for poetry, songwriting, and creative writing, implying context, but does not explicitly state when to use this tool versus alternatives or 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.
Find words that sound similar to the input. Useful for spelling correction, finding homophones, creating puns, or phonetic matching.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum number of results (1-50, default: 15) | |
| text | Yes | The text to match phonetically (can be a misspelling) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does not disclose side effects, auth requirements, or rate limits. It implies a read-only search but does not explicitly state the tool's safety profile.
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 with no fluff. It front-loads the core purpose and immediately adds use cases, making it efficient and easy to parse.
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 tool's simplicity (2 parameters, no output schema), the description adequately covers purpose and use cases. It could optionally describe the return format, but it is not critical for agent selection.
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?
Both parameters are described in the schema (100% coverage), so the description adds only marginal context (e.g., 'phonetic matching'). The description does not explain parameter semantics 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 finds words that sound similar, with specific use cases like spelling correction and homophones. It is distinct from sibling tools like find_synonyms or find_rhymes.
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 lists explicit use cases (spelling correction, homophones, puns, phonetic matching), providing clear guidance on when to use. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find synonyms (words with similar meanings) for a given word. Uses WordNet and corpus data. Optionally bias results toward a specific topic.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Maximum number of results (1-50, default: 10) | |
| word | Yes | The word to find synonyms for | |
| topic | No | Optional topic to bias results (e.g., 'music', 'medical') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description mentions data sources (WordNet, corpus) and topic biasing but does not disclose safety (read-only), error handling, or performance characteristics. More context needed for a robust behavioral profile.
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?
Two sentences with no filler. Core information is front-loaded, efficient, and easy to scan.
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 synonym lookup tool with well-documented schema, the description provides adequate context. Lacks details on return format or edge cases, but these are partially covered by the sibling tool set and the tool's straightforward nature.
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 descriptions cover all parameters (100% coverage), so baseline is 3. The description adds minimal value beyond the schema; 'Optionally bias' repeats schema text. No new parameter meanings are introduced.
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?
Clearly states the tool finds synonyms for a given word, specifying data sources (WordNet and corpus) and an optional topic bias. Distinct from siblings like find_antonyms or find_rhymes.
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?
No explicit guidance on when to use this tool versus siblings such as find_related_words or find_by_pattern. The description implies synonym lookup but does not provide conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a word including: definitions, part of speech, syllable count, pronunciation (IPA), and usage frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | The word to get information about |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the types of information returned (definitions, PoS, syllable count, IPA, frequency), which is good. However, it does not explain data source, error handling (e.g., word not found), or any limitations, leaving some behavioral gaps.
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 a single sentence with no wasted words. It efficiently lists the included attributes, making it easy to scan.
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 tool has only one parameter, no output schema, and no nested objects, the description is largely sufficient. It explains the return content. However, it omits possible errors or data sources, which would improve completeness for a production 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 description coverage is 100%, so baseline is 3. The description adds value by detailing what information will be returned, but does not add parameter-specific semantics beyond the schema's 'The word to get information about'.
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 verb 'Get' and the resource 'detailed information about a word', listing specific attributes (definitions, part of speech, etc.). This distinguishes it from sibling tools which focus on specific word relations like synonyms or rhymes.
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 this tool is for general word information, but there is no explicit guidance on when to use it versus siblings or when not to use it. Missing 'when-not' and alternative recommendations.
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. Dates show when Glama detected each change.
v1.0.0autocompletefind_adjectives_for_nounfind_antonymsfind_by_patternfind_nouns_for_adjectivefind_related_wordsfind_rhymesfind_similar_soundingfind_synonymsget_word_infoEach tool targets a distinct lexical relationship (synonyms, antonyms, rhymes, sound-alikes, pattern, related words, adjective-noun, noun-adjective, info, autocomplete) with no overlap. An agent can easily select the correct tool based on the desired operation.
Most tools follow a 'find_' prefix pattern (e.g., find_synonyms, find_rhymes), but 'get_word_info' and 'autocomplete' deviate. This is a minor inconsistency in an otherwise coherent naming scheme.
10 tools is a well-scoped set for a word query server. Each tool provides essential functionality without redundancy, making the surface manageable and purposeful.
The tools cover a broad range of word relationships: synonyms, antonyms, rhymes, phonetic matching, pattern matching, semantic relations, collocations, dictionary info, and autocomplete. There are no obvious gaps for common lexical queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Words MCP — wraps Datamuse API (free, no auth required)
MCP server exposing the AceDataCloud Fish Audio API (text-to-speech with voice conditioning)
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lacausecrypto/datamuse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server