Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cldf-mcp Which languages are SOV but use prepositions, and are they spread across families?"
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.
An MCP server that gives AI assistants grounded access to cross-linguistic data published in the CLDF format. Version 0.1 ships with:
WALS, the World Atlas of Language Structures: 192 typological features (word order, phonology, morphology…) for 2,660 languages, with sources for every datapoint;
Glottolog: the catalog of the world's ~27,000 languoids, their classification, alternate names, endangerment and description status.
Language models know WALS exists but are unreliable on specifics: which value a language has for feature 85A, or how many languages combine SOV order with prepositions. This server returns the actual data, with the release it came from and the reference behind it.
Family-aware counts. Related languages inherit features, so "400 languages do X" can mean "three big families do X". Every count comes with the number of distinct families (from Glottolog) and WALS genera, plus the share of the largest family, so the model can tell a cross-linguistic tendency from the signature of one lineage. WALS's balanced 100- and 200-language samples are available as filters.
Provenance everywhere. Each answer names the dataset, release and citation; datapoints carry their bibliographic sources and page numbers.
No silent guessing. bsq is WALS's code for Basque and the ISO code for Bassa, so the server
asks instead of picking one. "No data" is never reported as "absent".
Pinned, verified data. Datasets are fetched from tagged releases and checked against SHA-256 checksums before loading.
Related MCP server: U.S. Census Bureau Data API MCP
Requires Python 3.11+ and uv (or pip).
Claude Code
claude mcp add cldf -- uvx cldf-mcpClaude Desktop and other clients that use an mcpServers config:
{
"mcpServers": {
"cldf": {
"command": "uvx",
"args": ["cldf-mcp"]
}
}
}On first use the server downloads the pinned releases (about 40 MB) and builds a local SQLite database (about 35 MB) in a few seconds. To do this ahead of time:
uvx cldf-mcp setupThen ask things like:
Which languages in WALS are SOV but use prepositions? Are they spread across families?
Is "VSO implies prepositions" a real tendency? Check it within the WALS 200-language sample.
Give me Basque's word-order features, with sources.
How does WALS cover the Austronesian family? Which branches have the most data?
Tool | What it does |
| Loaded datasets, release versions, coverage, licenses and citations |
| Names (including alternate names and misspellings), ISO 639-3 codes, Glottocodes or dataset codes → ranked candidates with family, macroarea and which entries have data |
| Keyword search over feature names, chapters and value labels → feature IDs and possible values |
| Definition, chapter, authors and value distribution, counted by languages, families and genera; optional filters by macroarea, family/subgroup or WALS sample |
| Language × feature grid with values, comments, sources and full citations; unresolvable names are reported with candidates instead of failing the call |
| Everything about one language: Glottolog identity, lineage, endangerment, description status and all feature values |
| Languages matching up to 8 conditions (AND, with |
| Two features cross-tabulated: languages, families, genera and largest-family share per cell, zero cells kept, optional macroarea breakdown |
| Glottolog lineage, children (with how many dataset entries fall under each), sisters |
| Full bibliographic references for the source IDs cited in datapoints |
Resources:
cldf://guide/typology-caveats: how to use counts responsibly (sampling bias, areal effects,
coverage, citation). The server's instructions point the model to it.
cldf://datasets: versions, licenses and citations of the loaded data.
All tools are read-only and work offline once the data is prepared.
Setting | Default |
|
|
| none: extra TOML to add or override datasets (experimental, see below) |
|
|
Other commands: cldf-mcp info (where data lives, whether it is current) and
cldf-mcp setup --force (rebuild).
Any CLDF StructureDataset whose languages carry Glottocodes can be loaded alongside WALS. Feature tools, family counting and cross-dataset filters work on it automatically:
# my-datasets.toml
[datasets.mydata]
title = "My typological survey"
role = "features"
version = "v1.0"
base_url = "https://raw.githubusercontent.com/me/mydata/v1.0/cldf/" # or: local_path = "/path/to/cldf"
metadata = "StructureDataset-metadata.json"
license = "CC-BY-4.0"
citation = "Me. 2026. My typological survey."
[datasets.mydata.files] # every file the loader needs, with optional sha256 checksums
"StructureDataset-metadata.json" = ""
"languages.csv" = ""
"parameters.csv" = ""
"codes.csv" = ""
"values.csv" = ""cldf-mcp setup --config my-datasets.tomlThe server code is MIT-licensed. The data is not part of this package: it is downloaded from the
original releases, which are licensed under CC-BY-4.0.
If you publish results obtained with this server, cite the datasets (see DATA_LICENSES.md):
Dryer, Matthew S. & Haspelmath, Martin (eds.) 2013. The World Atlas of Language Structures Online. Leipzig: Max Planck Institute for Evolutionary Anthropology. https://wals.info (CLDF release v2020.6)
Hammarström, Harald & Forkel, Robert & Haspelmath, Martin & Bank, Sebastian. 2026. Glottolog 5.3. Leipzig: Max Planck Institute for Evolutionary Anthropology. https://glottolog.org
This is an independent project and is not affiliated with the WALS, Glottolog or CLDF teams.
WALS reflects the literature up to about 2013, and most features are coded for a few hundred languages. Percentages are of coded languages, not of the world's languages.
Family counts follow Glottolog, which does not recognise proposed macro-families (e.g. Altaic). Of the 17 WALS languages without a Glottocode, 10 are matched to a Glottolog family through WALS's family or genus name; the other 7 keep WALS's own label (e.g. "Niger-Congo").
Glottolog's full bibliography is not bundled; its references are returned as links.
0.2: Grambank, the first dataset that overlaps with WALS, with side-by-side comparison of related features.
0.3: PHOIBLE sound inventories and Lexibank wordlists
(get_inventory, get_forms).
git clone https://github.com/hsouf/cldf-mcp && cd cldf-mcp
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
pytest # offline tests on small fixtures (tests/fixtures)
pytest -m network # downloads the real pinned releases and checks known WALS counts
ruff check src tests && ruff format --check src testsSee RELEASING.md for publishing to PyPI and the MCP Registry.
Glottolog classification of a language or group: lineage, children (with how many dataset entries fall under each), sisters, and the number of languages below.
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | Language, family or subgroup: name or Glottocode. | |
| max_children | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds output semantics (children carry dataset-entry counts, plus a descendant count), which is useful context, but says nothing about truncation behavior, ordering, or error cases for unknown names.
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 front-loaded sentence that leads with the resource and then enumerates outputs. No filler, no restatement of the tool name or annotations.
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?
An output schema exists, so the description is not obliged to explain return values, and the annotations cover the safety profile. However, the silent default truncation of children at 40 (adjustable via max_children) is a real gap an agent needs in order to interpret results 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?
Schema description coverage is only 50%: 'language' is documented in the schema, but 'max_children' (default 40, range 0-200) is undocumented in both schema and description. The description mentions neither the parameter nor the fact that child lists are truncated by default, so it fails to compensate for the coverage gap.
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 names a specific resource (Glottolog classification) and enumerates the outputs: lineage, children with entry counts, sisters, and descendant count. That is far more informative than the bare tool name 'classification'. It does not explicitly contrast with siblings like language_profile or find_language, which would be needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the listed return contents: an agent can infer this is the tool for taxonomic/tree questions. There is no explicit 'use this instead of language_profile' or any stated precondition, so the routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-tabulate two features over the languages coded for both. Each cell gives languages, families and genera attesting the combination and the share of its largest family, so you can tell a cross-linguistic tendency from the signature of one big family. Use this to check implicational universals.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Restrict to a Glottolog family or subgroup. | |
| sample | No | Restrict to 'wals100' or 'wals200'. | |
| feature_a | Yes | First feature ID, e.g. 'wals:81A'. | |
| feature_b | Yes | Second feature ID, e.g. 'wals:85A'. | |
| macroarea | No | Restrict to one macroarea. | |
| by_macroarea | No | Also give each cell per macroarea. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the description correctly spends its words elsewhere: it explains the structure of each output cell and warns of a confound (one large family driving the result). That is genuine interpretive guidance an agent could not get from annotations or the output schema alone.
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?
Three sentences, front-loaded with the core operation, then the output semantics, then the use case. Every sentence carries weight; the middle sentence is long but is compensating for analytical ambiguity rather than padding.
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 an output schema present, the description needn't enumerate return fields, and it doesn't try. It covers purpose, cell content, and interpretive caveat. The only gap is that it never acknowledges the filtering parameters that materially change what gets cross-tabulated.
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 phrase 'languages coded for both' usefully clarifies that feature_a and feature_b are intersected rather than unioned, but the four optional filters (family, sample, macroarea, by_macroarea) receive no mention in the description at all.
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?
States a specific verb and resource ('Cross-tabulate two features') plus the exact population ('languages coded for both'), which immediately separates it from siblings like filter_languages or get_values. It also specifies what a cell contains, so an agent knows precisely what operation is being performed.
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 gives a concrete use case ('Use this to check implicational universals') and an analytical rationale (distinguishing a cross-linguistic tendency from one dominant family's signature). It does not name an alternative tool or state when not to use it, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find languages matching feature conditions, e.g. SOV order AND postpositions.
Returns match counts against the number of languages coded for all conditions (the denominator), with family and genus counts and the families contributing most matches, plus the matching languages.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum languages listed (counts are always complete). | |
| family | No | Restrict to a Glottolog family or subgroup, or Glottocode. | |
| sample | No | Restrict to 'wals100' or 'wals200'. | |
| macroarea | No | Restrict to one macroarea. | |
| conditions | Yes | All conditions must hold (AND). Combine features across datasets freely. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnly, idempotent, non-destructive), so the description's value is the added semantics it does supply: matches are counted against the denominator of languages coded for ALL conditions, and results include family/genus breakdowns and top contributing families. That denominator detail is genuinely non-obvious and affects interpretation. It does not discuss cost or performance of broad filters.
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, front-loaded with the purpose and followed by the return semantics. No filler, no restatement of the tool 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?
With an output schema present and full parameter coverage, the description only needs to frame the query model, which it does via the denominator explanation. Minor gap: it never notes the 8-condition cap or how the limit parameter interacts with the always-complete counts, though the schema covers both.
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 reinforces the AND semantics and gives an illustrative feature pairing, but adds no format, precedence, or interaction detail (e.g. how family/sample/macroarea intersect with conditions) beyond what the schema already documents.
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?
States a specific verb+resource ("Find languages matching feature conditions") and immediately grounds it with a concrete example (SOV order AND postpositions), which makes it distinguishable from find_language (single lookup) and language_profile. It stops short of naming a sibling to route away from, so it misses the 5 bar.
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 example implies the intended scenario (multi-feature filtering), but there is no explicit when-to-use/when-not guidance and no mention of how this differs from crosstab, which is the obvious alternative for multi-feature queries. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find languages by name or code. Returns Glottocodes, family, macroarea and which dataset entries have data.
Use this before other tools when a name might be ambiguous (e.g. 'Arabic' is a family; WALS has Arabic varieties). Candidates are ranked: exact codes, exact names, alternate names, then partial matches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Language name (any spelling or alternate name), ISO 639-3 code, Glottocode, or dataset code like 'wals:bsq'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's added value is the ranking behavior: exact codes, exact names, alternate names, then partial matches. That ranking is real behavioral context an agent cannot get from the schema, though it doesn't mention truncation behavior when results exceed limit.
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?
Front-loaded with the verb and returned fields, followed by the routing advice and the ranking rule. Every sentence earns its place and there is no redundant restatement of 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?
With an output schema present, the description needn't explain return structure, and it still usefully previews the key returned fields. An agent can call this correctly, with only the limit parameter's behavior left unaddressed.
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 50%: the query parameter is well documented in-schema (name, alternate name, ISO 639-3, Glottocode, or 'wals:bsq' form), so the description rightly doesn't repeat it. But the limit parameter (max 25) is undocumented in both places, and the description says nothing about result capping, so it does not compensate for the gap.
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?
States a specific verb and resource ('Find languages by name or code') and immediately names what is returned (Glottocodes, family, macroarea, dataset coverage). That combination distinguishes it from siblings like filter_languages or language_profile without needing to open their schemas.
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?
Explicitly prescribes ordering against the other tools ('Use this before other tools when a name might be ambiguous') and gives a concrete motivating example ('Arabic' is a family; WALS has Arabic varieties). It lacks an explicit when-not clause or a named alternative for the unambiguous case, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe one feature: definition, chapter and authors, and how its values are distributed, counted by languages, families and genera.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Restrict to a Glottolog family or subgroup ('Austronesian', 'Germanic') or Glottocode. | |
| sample | No | Restrict to a balanced sample: 'wals100' or 'wals200'. | |
| feature | Yes | Feature ID, e.g. 'wals:81A'. | |
| macroarea | No | Restrict to one macroarea: Africa, Australia, Eurasia, North America, Papunesia, South America. | |
| by_macroarea | No | Also break counts down by macroarea. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavioral context that results are aggregated counts grouped by languages, families and genera, but says nothing about behavior on unknown feature IDs or the effect of the optional filters.
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 dense sentence with the verb and resource front-loaded and no filler. It is slightly compressed in the trailing clause ('counted by languages, families and genera'), but every clause carries 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?
With a full output schema and rich annotations, the description only needs to convey purpose and the shape of the analysis, which it does. The remaining gap is not pointing at search_features as the way to obtain the required feature ID, which matters for a tool whose only required parameter is an identifier.
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 every parameter (family, sample, macroarea, by_macroarea, feature) is already documented in the schema. The description's mention of counting by families and genera is only loosely related to the family parameter and adds no syntax, format, or interaction detail beyond the schema, so baseline 3 applies.
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?
States a specific verb ('Describe') and a specific, singular resource ('one feature') and then enumerates the returned content: definition, chapter, authors, and value distributions. This implicitly separates it from the plural search_features, but it never names that sibling to make the distinction explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent infers it should call this once it already has a feature ID and wants detail plus aggregate counts. There is no explicit 'use this when' or 'use search_features to find the ID first' guidance, and no mention of 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.
Full bibliographic references for source IDs cited in datapoints.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | No | Dataset the IDs come from, e.g. 'wals'. | |
| source_ids | Yes | Source IDs as returned by get_values, e.g. ['Nekitel-1985'] (page suffixes like '[94]' are accepted). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds only that the output is full bibliographic references; it says nothing about how unknown or stale IDs are handled, or the 50-ID cap, which is the main operational constraint.
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 front-loaded sentence with no filler or redundancy. It is efficient, though the terseness leaves little room for the operational caveats an agent might want.
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 batch lookup with a full input schema, an output schema, and rich annotations, the description covers the essential contract. The remaining gaps (behavior for unknown IDs, dataset defaulting) are minor for this complexity level.
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% and the schema already explains both 'dataset' (with an example) and 'source_ids' (format, page-suffix tolerance, max 50). The description adds no parameter meaning beyond what the schema states, so the baseline 3 applies.
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 names a specific resource ('full bibliographic references') and the exact input domain ('source IDs cited in datapoints'), so the agent knows this is a citation-lookup tool. It does not name or contrast with any sibling tool, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'cited in datapoints' hints that this is a follow-up step after retrieving datapoints, but there is no explicit when-to-use, when-not-to-use, or named alternative. The agent must infer the workflow from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up specific datapoints: the value of each feature for each language, with sources, comments and full citations. Unresolvable names are reported in 'errors' with candidates instead of failing the call.
When several dataset entries share a Glottocode (e.g. Basque and Basque dialects), the main entry is used and the others are listed; pass a dataset ref like 'wals:bso' to pick a specific one.
| Name | Required | Description | Default |
|---|---|---|---|
| features | Yes | Feature IDs, e.g. ['wals:81A', 'wals:85A']. | |
| languages | Yes | Languages: names, Glottocodes, ISO codes or dataset refs ('wals:bsq'). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's job is to add operational context — and it does: unresolvable names are reported in 'errors' with candidates rather than failing, and the default tie-break behavior for shared Glottocodes is disclosed. It doesn't mention size/rate limits for the 50x50 cross product, which would have been the last useful detail.
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?
Front-loaded with what the call returns, then two tight paragraphs covering error semantics and disambiguation. Every sentence carries information; the parenthetical Basque example is a small luxury but aids comprehension.
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 an output schema present, return shape needn't be spelled out, and the description still flags the 'errors' field an agent must handle. Combined with the disambiguation rule, an agent can call this correctly; only the interaction with sibling query tools is left unaddressed.
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 both parameters documented and exemplified, so the baseline is 3. The description adds real meaning on top: it explains the default resolution when multiple dataset entries share a Glottocode and shows the dataset-ref override syntax ('wals:bso'), which the schema only gestures at.
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?
States a specific verb and resource: look up the value of each feature for each language, returning sources, comments and citations. That cross-product framing implicitly separates it from single-entity siblings like get_feature and language_profile, but no sibling is named explicitly, so differentiation is inferred rather than stated.
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?
Gives a concrete conditional rule for parameter choice: pass a dataset ref like 'wals:bso' when several entries share a Glottocode. However, it never says when to use this tool instead of crosstab, filter_languages or get_feature, so the when-to-use dimension is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything known about one language: Glottolog identity, classification, endangerment and description status, plus all its feature values per dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum values per dataset. | |
| dataset | No | Only show this dataset's values. | |
| language | Yes | Name, Glottocode, ISO 639-3 code or dataset ref. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a safe, read-only, idempotent, non-destructive operation. The description adds useful scope by saying the response includes identity, classification, endangerment and description status, and per-dataset feature values. It does not discuss pagination or default limits, but with an output schema present and strong annotations, that is a minor gap.
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, front-loaded sentence that identifies the resource and enumerates the returned information without wasted words. It is appropriately sized for a profile lookup 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?
Given the rich annotations, fully described schema, and presence of an output schema, the description provides enough context to understand what the tool returns and when it is useful. It could be slightly stronger by explicitly distinguishing itself from sibling lookup tools, but otherwise it is complete.
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 input schema already explains language, dataset, and limit semantics. The description reinforces the 'one language' and 'per dataset' framing but adds no syntax or format details beyond what the schema provides, so the 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 that this tool returns a comprehensive profile for one language, listing Glottolog identity, classification, endangerment, description status, and feature values. It is more specific than a generic lookup, but it does not explicitly contrast itself with siblings such as find_language or filter_languages.
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 phrase 'Everything known about one language' implies that this is the tool to use when a full language profile is needed, rather than a search or listing tool. However, it gives no explicit when-to-use guidance, exclusions, or named alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the loaded datasets with their release versions, coverage, licenses and how to cite them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered there. The description adds that entries carry release version, coverage, license and citation metadata, which is genuine extra context, but says nothing about result ordering, whether all datasets are returned or only 'loaded' ones are filtered out, or whether the list is complete.
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 front-loaded sentence with no filler. Every element (loaded datasets, release versions, coverage, licenses, citation) earns its place by telling the agent what comes back.
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 zero-parameter, read-only listing tool with full annotations and an output schema, the description covers scope and payload fields adequately. The only gap is the lack of any note about what "loaded" means or how complete/ordered the listing is.
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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is 100% and the empty argument object is self-evident.
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 states a specific verb and resource ("List the loaded datasets") and enumerates the metadata returned: release versions, coverage, licenses, citation info. That makes the tool's purpose clear without opening the schema. It doesn't contrast itself against siblings, but the siblings (find_language, get_feature, crosstab, etc.) are different enough that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent infers this is entry-point/discovery tooling because it returns dataset-level metadata. There is no explicit when-to-use statement and no mention of alternatives for a caller who actually wants feature or value data (e.g., search_features, get_values).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search typological features by keyword. Returns feature IDs, names, possible values and how many languages are coded for each.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Keywords such as 'word order', 'negation', 'tone', 'plural', or a feature ID like '81A'. | |
| dataset | No | Restrict to one dataset, e.g. 'wals'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered elsewhere. The description adds the shape of the result (IDs, names, values, language counts), but says nothing about the 15-item default cap or how an empty/ambiguous query behaves.
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 front-loaded sentences with zero filler: the action comes first, the return payload second. Nothing could be cut without losing 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?
An output schema exists, so return-value detail isn't strictly needed, and the tool is simple. Still missing is any hint about result capping/pagination via limit or how the dataset parameter scopes results, which matters for a search tool that silently defaults to 15 rows.
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 67%: query and dataset are documented in-schema, while limit has no description. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource ("Search typological features by keyword") and enumerates what comes back, so the agent knows this is a discovery/lookup tool. It does not name or contrast with the sibling get_feature, which would have made it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: keyword search suggests use when you don't already have a feature ID. There is no explicit when-to-use, no exclusion, and no pointer to get_feature for retrieving a known ID or to list_datasets for dataset discovery.
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.
v0.1.0classificationcrosstabfilter_languagesfind_languageget_featureget_sourceget_valueslanguage_profilelist_datasetssearch_featuresScored across 10 tools
Most tools have clearly distinct roles: find_language (name lookup), search_features (keyword search), get_feature (single feature detail), get_values (datapoint lookup), filter_languages (conditional query), crosstab (two-feature tabulation), classification (hierarchy), get_source (citations). There is some overlap between search_features/get_feature and between get_values/language_profile, but the descriptions clarify that the latter pairs operate at different granularities.
Seven tools follow a verb_noun pattern (list_datasets, find_language, search_features, get_feature, get_values, filter_languages, get_source), but three use bare noun names (language_profile, crosstab, classification). The conventions are mixed but still readable and semantically clear.
Ten tools is well-scoped for a typological-database explorer, with each tool covering a distinct query angle (discovery, lookup, filtering, aggregation, classification, sources). No tool feels redundant or padded.
The surface covers discovery (datasets, languages, features), retrieval (values, profiles, sources), and analysis (filtering, crosstab, classification), which is strong for a read-only typology server. Minor gaps exist, such as no direct export/aggregate-statistics tool, but core workflows are fully supported.
Grounds LLMs in real Latin: Wiktionary lemmas, Morpheus inflections, citations.
Research-backed lint + generation for agent context files (CLAUDE.md, AGENTS.md) + prompt enhancer.
Machine-readable utilities and datasets for AI agents.
Connects an AI assistant to your Lingard account (lingard.app), an app for learning languages with books, news and flashcards. Create topic word collections and add complete cards: translation, part of speech, pronunciation, synonyms, example sentences with translations, and images. Fill in missing fields on existing cards, rewrite example translations, and pause or resume collections, books and news in your daily study sessions. Every change can be previewed before it is saved, and saved words appear in the Lingard apps on iOS, Android and the web. Requires a Lingard account; sign-in uses OAuth.
