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., "@Sketch Engine MCP Server Show me collocations for 'artificial intelligence' in the British National Corpus"
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.
A tool that connects Claude (AI assistant) to Sketch Engine, enabling powerful corpus linguistics and text analysis directly in your conversations with Claude.
This server lets Claude access Sketch Engine's massive text databases (corpora) to help you with linguistic research, language learning, writing, and text analysis. You can ask Claude questions like:
"What are the most common collocations with 'artificial intelligence'?"
"Show me how the word 'literally' is used in modern English"
"Compare how 'affect' and 'effect' are used in academic writing"
Claude will use Sketch Engine's tools to give you detailed, corpus-based answers.
Related MCP server: Snowflake MCP Server
No technical knowledge required! Just download, configure, and go.
Download the standalone executable for your system from the releases page:
Linux: sketch-engine-mcp-linux-x64
macOS (Intel): sketch-engine-mcp-macos-x64
macOS (Apple Silicon/M1/M2/M3): sketch-engine-mcp-macos-arm64
Windows: sketch-engine-mcp-win-x64.exe
No installation needed! These are standalone executables that work out of the box.
After downloading, open Terminal and run:
chmod +x sketch-engine-mcp-linux-x64(Replace with your actual filename)
You need a free Sketch Engine account:
Click "Register" to create a free account (or log in if you have one)
After logging in, click your username in the top-right corner
Select "My Account"
Find the "API Key" section
Click "Generate API Key" if you don't have one
Copy your API key - you'll need it in the next step
Keep this key private! It's like a password for your Sketch Engine account.
You need to tell Claude about this server. Don't worry - it's just editing one configuration file.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Tip for macOS/Linux: Open Terminal and run:
mkdir -p ~/.config/Claude # Create directory if needed
nano ~/.config/Claude/claude_desktop_config.json # Edit fileCopy and paste this into the config file:
{
"mcpServers": {
"sketch-engine": {
"command": "/path/to/sketch-engine-mcp-linux-x64",
"env": {
"SKETCH_ENGINE_API_KEY": "your_api_key_here"
}
}
}
}Replace two things:
/path/to/sketch-engine-mcp-linux-x64 - The full path to where you downloaded the executable
your_api_key_here - Your actual API key from Step 2
Example (macOS):
{
"mcpServers": {
"sketch-engine": {
"command": "/Users/yourname/Downloads/sketch-engine-mcp-macos-arm64",
"env": {
"SKETCH_ENGINE_API_KEY": "abc123xyz789"
}
}
}
}Save the file and restart Claude Desktop (or Claude Code CLI).
Open Claude and try these example questions:
"Use Sketch Engine to list available corpora""Find collocations for 'climate change' in the EnTenTen21 corpus""Show me concordances for the word 'serendipity'"If it works, you'll see Claude using the Sketch Engine tools to answer your questions!
This server gives Claude access to these Sketch Engine tools:
Word Sketches: See how words are typically used (grammatical patterns, collocations)
Concordances: Find real examples of words or phrases in context
Word Lists: Generate frequency lists of words in any corpus
Word Comparison: Compare how two similar words are used differently
Collocations: Find words that commonly appear together
Frequency Analysis: Analyze how often words/phrases appear
Keyword Extraction: Find characteristic words by comparing two corpora
Custom Queries: Run advanced searches using CQL (Corpus Query Language)
"Compare the usage of 'effect' and 'affect' in academic English""What are the most common adjectives used with 'solution'?""Find examples of 'literally' being used in the EnTenTen corpus""Generate a word frequency list for the Susanne corpus""Show me concordances for 'break * ice' (phrasal pattern)"For more detailed examples and workflows, see docs/EXAMPLES.md.
Check that the path in your config file is correct (use full absolute path)
On Linux/macOS, make sure you ran chmod +x on the executable
Double-check that you copied your API key correctly from Sketch Engine
Make sure there are no extra spaces in the config file
Restart Claude Desktop (or Claude Code CLI)
Check that your config file JSON is valid (use a JSON validator online if needed)
See the detailed User Guide for step-by-step instructions with screenshots
Report issues on GitHub
If you want to build from source, contribute, or understand how this works:
DEVELOPMENT.md - Complete development guide
CLAUDE.md - AI assistant development instructions
Sketch Engine is a leading corpus management and text analysis tool used by linguists, lexicographers, translators, and language learners worldwide. It provides access to massive text databases (corpora) in 90+ languages.
See LICENSE file for details.
Execute arbitrary CQL (Corpus Query Language) queries. Documentation: https://www.sketchengine.eu/documentation/corpus-querying/. Use 'q' for simple queries or 'json' for complex queries with filters/sorts. Do not use both simultaneously.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | CQL query string. Examples: [lemma="run"] (lemma search), [word="the"] (word search), [tag="NN.*"] (POS tag), [lemma="get" & tag="V.*"] (combined conditions) | |
| json | No | JSON parameter for complex queries with filters, sorts, or parallel concordances. Use this instead of 'q' for advanced queries. | |
| refs | No | Structural attributes (metadata) to display (optional) | |
| attrs | No | Positional attributes to display (optional) | |
| corpname | Yes | Name of the corpus | |
| pagesize | No | Number of concordance lines to return | |
| usesubcorp | No | Name of subcorpus (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear full responsibility. It does not mention whether queries are read-only, performance implications, authorization requirements, or potential side effects. The only behavioral detail is the mutual exclusivity of 'q' and 'json'.
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-loading the core purpose and following with a concise usage directive. No wasted words; every sentence contributes meaning.
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?
With no output schema, the description should explain return values, pagination, or result format. It does not, leaving a significant gap for a powerful query tool. The tool's complexity demands more context.
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 the schema already documents each parameter. The description adds value by clarifying the relationship between 'q' and 'json' and providing usage guidance, which goes beyond the schema's individual parameter 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?
The description clearly states the tool executes arbitrary CQL queries, with a documentation link. It distinguishes from siblings by being the only one for custom queries, and specifies two usage modes (simple vs complex) to avoid ambiguity.
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 explicit guidance on when to use 'q' vs 'json' and warns not to use both simultaneously. While it does not directly compare with siblings, the context implies this tool is for non-standard queries not covered by specialized siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get collocations for a query
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query string | |
| cattr | Yes | Collocation attribute (e.g., 'word', 'lemma') | |
| format | No | Response format | json |
| corpname | Yes | Name of the corpus |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It does not disclose any behavioral traits such as read-only nature, rate limits, or authentication needs beyond the implied 'get' prefix.
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 short sentence), which is efficient but at the cost of providing minimal useful information beyond the name.
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 4 parameters and no output schema or annotations, the description is insufficiently complete. It omits details about return format, pagination, or how collocations are computed.
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. The description adds no additional meaning beyond the schema parameter descriptions; it merely restates the tool 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?
Description clearly states the tool retrieves collocations based on a query. It is distinct from siblings like get_concordance or get_wordlist, though it could be more specific about the context (e.g., corpus-based).
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 guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for concordance lines in a corpus
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query string (CQL syntax) | |
| corpname | Yes | Name of the corpus | |
| pagesize | No | Number of concordance lines to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden for behavioral disclosure. It only states the high-level purpose without detailing behavior such as output format, pagination, permission requirements, or side effects.
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 7-word sentence, very concise. However, it omits important details; conciseness should not come at the expense of completeness. It earns its place but leaves gaps.
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 search tool with 3 parameters, no output schema, and many siblings, the description is insufficient. It does not explain what a concordance line is, result ordering, error handling, or when to prefer this tool over execute_cql_query.
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% with each parameter having a clear description (q: CQL syntax, corpname: corpus name, pagesize: number of lines). The tool description adds no additional semantic value beyond the schema, so baseline 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 'Search for concordance lines in a corpus' clearly identifies the verb (search) and the resource (concordance lines in a corpus). However, it does not differentiate from siblings like execute_cql_query, which may also search corpora, so it lacks sibling distinction.
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 guidance is provided on when to use this tool versus alternatives like execute_cql_query or get_wordlist. The description does not specify context, prerequisites, 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.
List available corpora
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not state that the operation is read-only, what data is returned, or any side effects. The brief description adds no transparency beyond the tool's name.
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 concise sentence that immediately states the purpose. It is front-loaded and contains no wasted words, but could potentially include more context without being verbose.
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 list tool with one parameter and no output schema, the description is somewhat complete in stating the action. However, it does not describe the return format or any relevant behavior, which an agent needs to interpret results. Given the lack of output schema, more detail would be beneficial.
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% and the single parameter 'format' is fully described (enum with default). The description does not add any additional meaning beyond what the schema already provides, meeting the baseline of 3.
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 'List available corpora' uses a specific verb 'List' and resource 'corpora', clearly distinguishing it from sibling tools like get_corpus_info (which gets details on a specific corpus) and get_concordance (which retrieves concordance lines).
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 guidance is provided on when to use this tool versus alternatives, such as starting with this tool before calling get_corpus_info for specific corpus details. The description does not mention prerequisites or common workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics and information about a corpus
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format | json |
| corpname | Yes | Name of the corpus | |
| usesubcorp | No | Name of subcorpus (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states what the tool does without mentioning safety (e.g., read-only), side effects, or required permissions. The description adds minimal behavioral context beyond the basic purpose.
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?
A single concise sentence, well front-loaded with the action and resource. While it could include a bit more detail (e.g., what 'statistics' entails), it remains efficient without waste.
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 tool has 3 parameters and no output schema. The description does not explain what 'statistics and information' the tool returns, leaving a significant gap for an agent to understand the full capability. For a tool of this complexity, more completeness is needed.
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% with all parameters described. The description does not add any extra semantic information about parameters beyond what the schema provides, meeting the baseline expectation.
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 retrieves statistics and information about a corpus, which distinguishes it from siblings like get_corpora (list corpora) and get_collocations. However, 'statistics and information' is somewhat vague; specifying the type of info would improve clarity.
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 guidance on when to use this tool instead of alternatives. No context about prerequisites or scenarios is given, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get frequency distribution for a query
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Query string | |
| format | No | Response format | json |
| ml1ctx | Yes | Context position for first attribute | |
| ml2ctx | No | Context position for second attribute (optional) | |
| ml1attr | Yes | First frequency attribute | |
| ml2attr | No | Second frequency attribute (optional) | |
| corpname | Yes | Name of the corpus |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the basic function. No mention of output format, data scope, rate limits, or side effects.
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, but it omits important information, making it too terse for a tool with 7 parameters.
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 complexity (7 params, no output schema, no annotations), the description is inadequate. It does not explain the meaning of frequency distribution or how optional parameters interact.
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 the baseline is 3. The description adds no additional parameter context beyond what the schema already provides.
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 retrieves a frequency distribution for a query, which is specific and distinguishable from sibling tools like get_concordance or get_collocations.
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 guidance is provided on when to use this tool versus alternatives, nor does it specify prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract keywords by comparing two corpora
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format | json |
| corpname | Yes | Name of the focus corpus | |
| wlmaxitems | No | Maximum number of keywords | |
| ref_corpname | Yes | Name of the reference corpus |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action without revealing how comparison works, statistical methods used, or other behavioral traits like performance or limitations.
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 concise sentence with no waste. However, it could be structured to front-load more critical operational details without increasing length significantly.
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 no annotations, no output schema, and 4 parameters, the description is incomplete. It lacks explanation of what 'keywords' means in this context, output format details, and any usage nuances, making it insufficient for full understanding.
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 the schema already documents all parameters with descriptions. The tool description adds no additional meaning beyond the schema, achieving the baseline adequacy of 3.
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 'Extract keywords by comparing two corpora' clearly states the specific verb (Extract), the resource (keywords), and the method (comparing two corpora), which distinguishes it from siblings like get_collocations or get_frequency_distribution.
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 offers no guidance on when to use this tool vs alternatives. It does not specify contexts for which keyword extraction via corpus comparison is appropriate or when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a wordlist from a corpus
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format | json |
| wlattr | No | Attribute for wordlist (word, lemma, tag, etc.) | word |
| corpname | Yes | Name of the corpus | |
| wlmaxitems | No | Maximum number of items to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It says 'generate' but does not disclose whether the operation is read-only or if any side effects exist. No behavioral traits are described.
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 concise sentence with no wasted words. It is front-loaded and appropriately sized for a simple tool.
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 tool has no output schema, so the description should provide hints about return values. It only says 'generate a wordlist', leaving the output format and structure unspecified. For a tool with 4 parameters and no output schema, the description is too thin.
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 has 100% description coverage over all four parameters. The description adds no additional meaning beyond the schema's parameter descriptions, so a baseline 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 verb 'generate' and the resource 'a wordlist from a corpus', which is specific and not a tautology. However, it does not differentiate from sibling tools like get_frequency_distribution, which may also produce lists of words.
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 guidance is provided on when to use this tool versus alternatives (e.g., get_concordance, get_frequency_distribution). There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get word sketch (grammatical relations) for a lemma
| Name | Required | Description | Default |
|---|---|---|---|
| lemma | Yes | Lemma to analyze | |
| format | No | Response format | json |
| corpname | Yes | Name of the corpus |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states what the tool gets, but provides no information about side effects, permissions, performance, or output behavior. For a retrieval tool, basic safety is implied but not explicit.
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, concise sentence that front-loads the core function. No unnecessary words or repetition.
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 tool has no output schema and the concept of a 'word sketch' is not explained. The description does not tell the agent what the response will contain or how to interpret the grammatical relations, making it insufficient for correct 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 the baseline is 3. The description does not add additional meaning beyond what the schema already provides for parameters like 'lemma', 'format', and 'corpname'.
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 resource 'word sketch (grammatical relations) for a lemma'. It distinguishes from the sibling 'get_word_sketch_diff' which is a different 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?
No guidance is provided on when to use this tool versus alternatives like 'get_collocations' or 'get_concordance'. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare the behavior of two words/lemmas via their collocations. Returns scores indicating which collocation is more typical of which word, useful for observing differences between similar words.
| Name | Required | Description | Default |
|---|---|---|---|
| lpos | No | Part of speech filter (e.g., 'n' for noun, 'v' for verb) (optional) | |
| lemma | Yes | First lemma to compare | |
| format | No | Response format | json |
| lemma2 | Yes | Second lemma to compare | |
| diff_by | No | Comparison mode: 'lemma' compares two lemmas (default), 'word form' compares word forms of same lemma, 'subcorpus' compares same lemma in different subcorpora (optional) | |
| minfreq | No | Minimum frequency threshold for collocations (optional) | |
| corpname | Yes | Name of the corpus | |
| subcorp1 | No | First subcorpus name (requires diff_by='subcorpus') (optional) | |
| subcorp2 | No | Second subcorpus name (requires diff_by='subcorpus') (optional) | |
| maxcommon | No | Maximum number of common collocations to show (optional) | |
| wordform1 | No | First word form to compare (requires diff_by='word form') (optional) | |
| wordform2 | No | Second word form to compare (requires diff_by='word form') (optional) | |
| maxexclusive | No | Maximum number of exclusive collocations per word (optional) | |
| separate_blocks | No | Separate collocations into blocks by grammatical relation (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it compares collocations and returns scores but does not disclose limitations, required permissions, rate limits, or response structure beyond scores.
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?
Single sentence is concise and front-loaded with purpose. No wasted words, though could benefit from slight elaboration on how scores work.
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 complexity (14 parameters) and no output schema, the description is adequate but incomplete. It lacks details on response format, sorting, or edge cases, but schema covers parameters well.
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. The description adds minimal value beyond schema—just mentions 'collocations' and 'scores' but does not explain how scores are calculated or interpreted.
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 compares two words/lemmas via collocations and returns scores indicating which collocation is more typical. It explicitly mentions usefulness for observing differences between similar words, distinguishing it from siblings like get_word_sketch (single word) and get_collocations (no comparison).
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?
Description implies usage for comparing similar words but does not explicitly state when to use this tool over alternatives like get_word_sketch or get_collocations. No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct linguistic operation (corpus info, wordlist, concordance, word sketch, collocations, keywords, frequency, CQL queries, comparison), with no overlapping purposes.
All tools follow a verb_noun pattern starting with 'get_', except 'execute_cql_query' which uses 'execute_'. This minor deviation prevents a perfect score.
10 tools cover a comprehensive range of corpus analysis operations without being excessive. The count is well-suited for the domain.
The set covers core corpus functions (list, info, wordlist, concordance, word sketch, collocations, keywords, frequency, CQL, comparison). While no glaring gaps exist, a tool for lemma extraction or token listing could further enhance completeness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Live SEO workflow tools for Claude Code, Codex, and AI agents.
One workspace of tools for Claude and ChatGPT: connect 600+ apps, generate media, build tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ricCap/sketch-engine-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
