Islam West Africa Collection (IWAC)
Server Details
Read-only access to the Islam West Africa Collection via Hugging Face datasets.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- fmadore/iwac-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 25 of 25 tools scored. Lowest: 2.9/5.
Most tools have clearly distinct purposes, targeting specific subsets or actions. However, the general `search` tool overlaps with the dedicated search_* tools (e.g., search_articles, search_references), though descriptions clarify that `search` is for cross-category queries while filtered queries should use the specific tools.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_article, list_subjects, search_articles). The only minor deviation is `fetch` instead of `get_item`, but the verb style remains uniform, and no naming conventions are mixed.
With 25 tools covering search, retrieval, listing, and statistics across six item types (articles, publications, references, documents, audiovisual, index), the count is well-scoped for the collection's breadth. Each tool has a clear purpose, and the number is neither too thin nor excessive.
The tool surface provides comprehensive read-only operations: search, fetch, and aggregate statistics. However, there are minor gaps such as the lack of a batch retrieval tool and no explicit listing for all articles or publications (though `search_documents` can list all with no arguments, others require a keyword).
Available Tools
34 toolsfetchFetch IWAC itemRead-onlyIdempotentInspect
Retrieve the full text and metadata of one IWAC item by an id returned from search (format ':', e.g. 'articles:28576'). Returns {id, title, text, url, metadata}: text is the item's OCR / abstract / transcription / description, url is the canonical islam.zmo.de link to cite, and metadata holds the remaining fields (author, date, country, newspaper, AI sentiment, …). Categories: articles, publications, references, documents, index, audiovisual, images.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Item id from search, e.g. 'articles:28576' or 'references:11045' |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | No | |
| text | Yes | |
| title | No | |
| category | Yes | |
| metadata | Yes | |
| text_truncated | No | |
| recommended_tool | No | |
| recommended_usage | No |
get_articleGet article detailsRead-onlyIdempotentInspect
Get one article (by id): full metadata, the AI abstract (description_ai), Gemini sentiment, and OCR text. Pass a keyword to get ~2000-char excerpts around each match instead of the full (capped) OCR.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Return excerpts around matches instead of the full OCR (accent-insensitive) | |
| article_id | Yes | ||
| max_excerpts | No | Default 10, max 25 | |
| context_chars | No | Default 2000, max 5000 |
get_audiovisualGet audiovisual detailsRead-onlyIdempotentInspect
Get one audiovisual record by id, including creator/publisher, media URL, duration, medium, subjects, places, language, source, and IWAC URL.
| Name | Required | Description | Default |
|---|---|---|---|
| audiovisual_id | Yes |
get_collection_statsCollection statisticsRead-onlyIdempotentInspect
Overall statistics for every IWAC subset, including fulltext_coverage — how many items in each subset actually carry searchable full text in this public dataset. Read that before treating any keyword count as a full-text census.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| view | Yes | |
| date_range | No | |
| dataset_url | Yes | |
| fulltext_note | No | |
| subset_counts | Yes | |
| total_records | Yes | |
| failed_subsets | No | |
| collection_name | Yes | |
| newspaper_count | No | |
| fulltext_coverage | No | |
| articles_by_country | No |
get_cooccurrenceCo-occurrence matrixARead-onlyIdempotentInspect
How often the top values of a multi-valued field appear on the SAME item — a subject/place co-mention matrix. Answers 'what is X discussed alongside' without reading anything: the pair counts are the structure of the tagging. Returns the top values, the full symmetric matrix (diagonal = each value's own count) and the strongest pairs.
| Name | Required | Description | Default |
|---|---|---|---|
| field | No | subject (default) | spatial | author | language | |
| top_n | No | Values on each axis (default 15, max 30) | |
| subset | No | articles (default) | publications | references | |
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | ONE French concept keyword; substring over the subset's text fields | |
| subject | No | Exact subject tag (pipe-aware) | |
| date_from | No | YYYY-MM-DD (or YYYY) | |
| newspaper | No | Newspaper (articles) or periodical/series title (publications) |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| view | Yes | |
| field | Yes | |
| matrix | Yes | |
| subset | Yes | |
| values | Yes | |
| filters | Yes | |
| top_pairs | Yes | |
| total_matches | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond these by explaining that 'the pair counts are the structure of the tagging' and describing the output content (top values, symmetric matrix, strongest pairs). No contradictions.
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, both front-loaded with essential information. The first sentence explains the purpose and output, the second adds details. Every sentence is earned with no wasted words.
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 9 optional parameters with clear schema descriptions and an output schema exists, the description is complete. It explains the tool's functionality, output, and usage in a way that allows an agent to select and invoke it 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 100%, so baseline is 3. The description does not add additional meaning to parameters beyond what the schema provides. The parameter descriptions in the schema are already clear and detailed.
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 returns a co-occurrence matrix for a multi-valued field, answering 'what is X discussed alongside'. It specifies the output includes top values, symmetric matrix, and strongest pairs. The name and title are consistent, and the tool is distinguished from siblings like get_field_distribution and get_semantic_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool answers co-occurrence questions 'without reading anything', providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternative tools for similar but different queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_country_comparisonCompare countriesRead-onlyIdempotentInspect
Compare article counts, newspaper counts, date ranges, and Gemini polarity across countries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| view | Yes | |
| countries | Yes | |
| total_countries | Yes |
get_documentGet document detailsRead-onlyIdempotentInspect
Get one archival document (by id): full metadata, AI description, and OCR text. Pass a keyword to get ~2000-char excerpts around each match instead of the full (capped) OCR — useful for long documents.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Return excerpts around matches instead of the full OCR (accent-insensitive) | |
| document_id | Yes | ||
| max_excerpts | No | Default 10, max 25 | |
| context_chars | No | Default 2000, max 5000 |
get_field_distributionRank a field's valuesARead-onlyIdempotentInspect
Rank the values of one multi-valued field across a filtered set — the direct way to answer 'which places does this coverage name most', 'who signs these articles', 'what subjects dominate'. Pipe-joined fields (subject, spatial, author, language, country) are split, so an article tagged 'Prière|Ramadan' counts once for each. Optional over_time adds the per-year share of items that carry ANY value for the field, which is how you see e.g. bylines appearing as the press professionalises.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | subject | spatial | author | language | newspaper | country | |
| top_n | No | Values returned (default 25, max 100) | |
| subset | No | articles (default) | publications | references | |
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | ONE French concept keyword; substring over the subset's text fields | |
| subject | No | Exact subject tag (pipe-aware) | |
| date_from | No | YYYY-MM-DD (or YYYY) | |
| newspaper | No | Newspaper (articles) or periodical/series title (publications) | |
| over_time | No | Also return the per-year share of items carrying a value |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| view | Yes | |
| field | Yes | |
| subset | Yes | |
| values | Yes | |
| filters | Yes | |
| other_values | No | |
| total_matches | Yes | |
| distinct_values | Yes | |
| coverage_by_year | No | |
| items_with_value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds behavioral detail about splitting pipe-joined fields and the over_time parameter's per-year share calculation, which is valuable context beyond annotations.
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 concise, well-structured sentences that front-load the purpose and then add key details. Every sentence adds value without redundancy.
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 10 parameters and an output schema present, the description covers the main behavior and a key nuance (pipe splitting, over_time). It does not detail every parameter or return format, but the output schema fills that gap.
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 already covers 100% of parameters with descriptions. The tool description adds meaning by explaining the purpose of the tool and clarifying how the field parameter works (pipe-joined fields split). Some parameters like top_n are not further elaborated, but overall the description complements the schema well.
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 ranks values of a multi-valued field across a filtered set, with specific examples like 'which places does this coverage name most'. It distinguishes itself by mentioning pipe-joined field splitting and optional over_time analysis, differentiating from sibling tools like get_place_distribution or get_temporal_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?
Description explicitly frames use cases with 'the direct way to answer' questions, guiding when to use. It does not explicitly state when not to use or alternative tools, but the context of sibling tools and the focused purpose provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_imageGet photograph detailsRead-onlyIdempotentInspect
Get one photograph by id: title, photographer, capture date, place and coordinates, subjects, rights, the IIIF manifest, and the full-resolution image_url. The server returns URLs, not image bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes |
get_index_entryGet index entry detailsRead-onlyIdempotentInspect
Get full details of an index entry by id (raw dataset columns, French names — Titre, Prénom, Coordonnées…).
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
get_lexical_metricsPress language metricsARead-onlyIdempotentInspect
Readability, lexical richness and length of the press text, averaged by year, newspaper or country. Lisibilite_OCR is a French readability score (higher = easier); Richesse_Lexicale_OCR is MATTR, a moving-average type-token ratio that is ALREADY length-robust — do not normalise it by word count or bin it by length. Readability is computed against a French lexicon, so non-French items are excluded from that metric (and counted in readability_excluded) rather than reported as unreadable; MATTR and word count need no lexicon and cover everything. Only items whose full text ships in this public dataset carry these columns at all.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Groups returned when grouping by newspaper (default 20, max 60) | |
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | ONE French concept keyword; substring over the subset's text fields | |
| subject | No | Exact subject tag (pipe-aware) | |
| group_by | No | year (default) | newspaper | country | |
| date_from | No | YYYY-MM-DD (or YYYY) | |
| newspaper | No | Newspaper (articles) or periodical/series title (publications) |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| view | Yes | |
| groups | Yes | |
| filters | Yes | |
| metrics | Yes | |
| group_by | Yes | |
| total_matches | Yes | |
| readability_excluded | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds valuable behavioral context: readability uses French lexicon and excludes non-French items (counted in readability_excluded), MATTR covers everything, and only items with full text in dataset carry columns. No contradiction.
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 main purpose. Some detail on metrics is necessary, but could be slightly more concise. No unnecessary sentences.
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 presence of an output schema, the description does not need to explain return values. It covers key behavioral details (exclusion, coverage, idempotency) adequately for an 8-parameter tool with no required parameters.
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 descriptions for all 8 parameters. The description does not add significant meaning beyond the schema; it focuses on metrics rather than parameter usage. 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?
Clearly states it returns readability, lexical richness, and length metrics averaged by year, newspaper, or country. The specific metrics (Lisibilite_OCR, MATTR) and their properties are described, distinguishing it from sibling tools like get_temporal_distribution or get_country_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?
Specifies the aggregation dimensions (year, newspaper, country) via group_by parameter. Provides guidance on interpreting MATTR as already length-robust and not to be normalized. Does not explicitly state when not to use, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_newspaper_statsNewspaper statisticsRead-onlyIdempotentInspect
Per-newspaper article counts and date ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Togo (accents optional) |
Output Schema
| Name | Required | Description |
|---|---|---|
| view | Yes | |
| newspapers | Yes | |
| country_filter | No | |
| total_articles | Yes | |
| total_newspapers | Yes |
get_place_distributionPlaces on a mapARead-onlyIdempotentInspect
Places named by a filtered set of items, joined to the index's authority records so each carries coordinates where the index has them. Use this rather than get_field_distribution when the question is geographic — where coverage clusters — and the plain ranking when it is not. Only Lieux index entries are geocoded (555 of 683); persons, organisations and events carry no coordinates and never will, and any named place with no index entry comes back under ungeocoded rather than being dropped.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Geocoded places returned (default 60, max 200) | |
| subset | No | articles (default) | publications | references | |
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | ONE French concept keyword; substring over the subset's text fields | |
| subject | No | Exact subject tag (pipe-aware) | |
| date_from | No | YYYY-MM-DD (or YYYY) | |
| newspaper | No | Newspaper (articles) or periodical/series title (publications) |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| view | Yes | |
| places | Yes | |
| subset | Yes | |
| filters | Yes | |
| ungeocoded | No | |
| total_matches | Yes | |
| items_by_country | No | |
| items_with_place | Yes | |
| ungeocoded_mentions | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds beyond this by noting that only 'Lieux' entries are geocoded (555 of 683) and that ungeocoded items appear under 'ungeocoded' rather than being dropped. This provides essential context for interpreting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, usage guidance, and a caveat. Every sentence adds value, no redundancy, well front-loaded.
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 8 parameters, output schema, and strong annotations, the description covers all necessary context: purpose, when to use, behavioral quirks (geocoding limits). No gaps identified.
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 8 parameters having descriptions in the schema. The description does not add parameter details, but the schema itself is sufficient. 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 the tool returns places named by items with coordinates from authority records, and explicitly distinguishes from get_field_distribution by focusing on geographic queries. The verb 'get' and resource 'place_distribution' are well explained.
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: 'Use this rather than get_field_distribution when the question is geographic — where coverage clusters — and the plain ranking when it is not.' It also clarifies limitations about which index entries are geocoded and how ungeocoded items are handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_publication_fulltextGet publication full textRead-onlyIdempotentInspect
Full OCR text of a publication, optionally returning ~2000-char excerpts around keyword matches (accent-insensitive; capped — see match_count vs excerpts_returned).
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | ||
| max_excerpts | No | Default 10, max 25 | |
| context_chars | No | Default 2000, max 5000 | |
| publication_id | Yes |
get_referenceGet reference detailsRead-onlyIdempotentInspect
Full bibliographic record for one academic reference (by id), including the complete abstract (present for ~51% of references), subjects, DOI/URL, and host-work details (book, volume, issue, pages).
| Name | Required | Description | Default |
|---|---|---|---|
| reference_id | Yes |
get_semantic_mapSemantic scatterARead-onlyIdempotentInspect
A 2-D scatter of a filtered set, projected from the stored 768-dimension embeddings by PCA. Shows which items sit near each other in meaning — where a set splits into distinct strands and where it is one cloud. Read explained_variance before drawing any conclusion: with 768 dimensions the first two components usually carry a modest share, and a scatter explaining 6% of the variance is a much weaker claim than one explaining 40%. This is PCA, not UMAP: it spreads the broadest axes of variation and flattens fine cluster structure, so it is not comparable to the semantic landscapes on islam.zmo.de. Needs no API key — the vectors are a column in the dataset — but only items whose full text ships are embedded at all. NOTE the payload scales with limit: a point cloud is a chart, not something a text-only client can read, so for those the useful part is the explained-variance summary rather than the coordinates. Keep limit low unless a chart is going to be drawn.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items projected (default 300, max 2000) | |
| subset | No | articles (default) | publications | references | |
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | ONE French concept keyword; substring over the subset's text fields | |
| subject | No | Exact subject tag (pipe-aware) | |
| color_by | No | country | newspaper | subject | lda_topic_label | gemini_polarite | |
| date_from | No | YYYY-MM-DD (or YYYY) | |
| newspaper | No | Newspaper (articles) or periodical/series title (publications) |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| view | Yes | |
| points | Yes | |
| subset | Yes | |
| filters | Yes | |
| color_by | No | |
| projected | Yes | |
| total_matches | Yes | |
| explained_variance | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), description adds that no API key is needed, vectors are stored, payload scales with limit, and explains the interpretation caveats for PCA. No contradictions.
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 informative but slightly verbose. It front-loads the main purpose and then provides important caveats in a logical order. Every sentence adds value, though some could be tightened.
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 (9 optional parameters, PCA explanation), the description is thorough: covers purpose, usage, limitations, interpretation, and connects to the output schema. No gaps 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%, so baseline is 3. The description adds some contextual value (e.g., keep limit low unless chart drawn) but does not substantially expand on parameter meanings beyond what the schema 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 it produces a 2-D scatter from PCA on embeddings to show semantic similarity. It distinguishes itself from other tools by explicitly comparing to UMAP and the islam.zmo.de landscapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (to see semantic groupings), cautions about interpreting explained variance, notes limitations (only items with full text are embedded), and advises text-only clients to focus on explained-variance summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sentiment_distributionAggregate AI sentimentRead-onlyIdempotentInspect
Aggregate AI polarity, centrality and subjectivity across a filter set. Three models scored every article independently — gemini (default), chatgpt and mistral — so model:"all" returns each one's distribution plus how often they AGREE. Treat disagreement as a fact about the judgement rather than noise: in a set where the three models split on polarity, no single model's number should be quoted alone. Scores cover every article whether or not its full text ships, so these shares are not subject to the OCR coverage limit.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | gemini (default) | chatgpt | mistral | all — "all" adds the cross-model agreement | |
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Togo (accents optional) | |
| subject | No | ||
| newspaper | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| view | Yes | |
| model | Yes | |
| models | No | |
| filters | Yes | |
| by_model | No | |
| agreement | No | |
| subjectivity | No | |
| total_articles | Yes | |
| agreement_matrix | No | |
| polarity_distribution | No | |
| centrality_distribution | No |
get_similar_itemsFind similar itemsARead-onlyIdempotentInspect
The items nearest to a given one in meaning, by cosine similarity over the stored embeddings. Answers 'what else is like this' without a keyword — it finds pieces on the same event or theme that share no vocabulary. A neighbour above ~0.85 is usually the same story reprinted or lightly rewritten, which is how to spot syndication in this corpus; 0.6-0.8 is 'same subject, different piece'. Needs no API key: the item's own vector is a column, so nothing has to be embedded at request time. This is per-item, NOT the corpus-wide near-duplicate sweep — that is an all-pairs job and belongs offline.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Item id — either a bare o:id ('3064') or the namespaced form search returns ('articles:3064') | |
| limit | No | Neighbours returned (default 12, max 50) | |
| subset | No | articles (default) | publications | references | |
| min_score | No | Drop neighbours below this cosine similarity (0-1) |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| view | Yes | |
| source | Yes | |
| subset | Yes | |
| neighbours | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral details beyond annotations: it uses stored embeddings, requires no API key, operates per-item, and explains how similarity scores relate to content relationships (syndication vs. same subject).
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 slightly long (5 sentences) but every sentence contributes meaning. It is front-loaded with the core purpose and efficiently provides context, though minor trimming could improve conciseness.
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 moderate complexity (4 parameters, output schema exists), the description fully covers the use case, input requirements, behavior, and output interpretation. No critical gaps remain.
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 parameter descriptions. The description adds value by explaining the 'id' parameter can be bare or namespaced and implicitly guides use of 'min_score' through score thresholds. This exceeds 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 clearly states the tool finds items nearest in meaning using cosine similarity of embeddings. It distinguishes itself from keyword search and corpus-wide near-duplicate detection, providing a specific verb-resource pair and clarifying its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (to find similar items without keywords) and what it is not (the corpus-wide near-duplicate sweep). It also provides interpretative thresholds for similarity scores, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_temporal_distributionCoverage over timeRead-onlyIdempotentInspect
Counts of matching items per year (or month) — the direct way to chart coverage trends over time instead of paging through search results. Defaults to articles; also works on publications, references, documents, audiovisual, and images. Accepts the same filters as the corresponding search_* tool (keyword = ONE substring over the subset's text fields, country, newspaper/series, subject, date range). Optional group_by=country|newspaper returns one distribution per group. Items dated only to a year keep a bare-year key even at month granularity; undated items are counted in undated_count, never dropped silently.
| Name | Required | Description | Default |
|---|---|---|---|
| subset | No | articles (default) | publications | references | documents | audiovisual | |
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | ONE French concept keyword (French/English for references); substring over the subset's text fields | |
| subject | No | Exact subject tag (pipe-aware) | |
| group_by | No | country | newspaper — one distribution per group value | |
| date_from | No | YYYY-MM-DD (or YYYY) | |
| newspaper | No | Newspaper (articles) or periodical/series title (publications) | |
| granularity | No | year (default) | month |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| view | Yes | |
| subset | Yes | |
| filters | Yes | |
| group_by | No | |
| dated_count | Yes | |
| granularity | Yes | |
| distribution | No | |
| total_matches | Yes | |
| undated_count | Yes | |
| distribution_by_group | No |
get_topic_distributionTopic distributionARead-onlyIdempotentInspect
How a filtered set distributes across the precomputed LDA topics, each labelled by its top terms (articles carry 30 topics and are ~99.5% classified; references have their own 33-topic model and only ~46% carry an assignment, so read its classified against total_matches). Topics are assigned offline over the full text, so they describe what a piece is ABOUT rather than which words it contains — use this instead of keyword counting to map a corpus. Optional over_time returns per-year counts for the leading topics. min_prob keeps only articles where the topic is at least that dominant (mean assignment probability is 0.34, so 0.5 is already a strong filter).
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Topics given their own band in over_time (default 8, max 15) | |
| subset | No | articles (default) | references | |
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | ONE French concept keyword; substring over the subset's text fields | |
| subject | No | Exact subject tag (pipe-aware) | |
| min_prob | No | 0-1; keep only assignments at or above this probability | |
| date_from | No | YYYY-MM-DD (or YYYY) | |
| newspaper | No | Newspaper (articles) or periodical/series title (publications) | |
| over_time | No | Also return per-year counts for the leading topics |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| view | Yes | |
| subset | Yes | |
| topics | Yes | |
| filters | Yes | |
| periods | No | |
| classified | Yes | |
| total_matches | Yes | |
| series_by_topic | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: topics are assigned offline over full text, so they describe 'aboutness' rather than word occurrence. No contradictions with annotations.
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 well-structured, starting with the core concept and then details. Every sentence adds value, though it is slightly verbose. Front-loading the key distinction from keyword counting is effective.
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 10 parameters, full schema coverage, and an output schema, the description is remarkably complete. It explains the behavior for both subsets, the meaning of topic assignments, and provides usage tips for parameters like min_prob and over_time. No gaps.
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 value by explaining min_prob with a typical mean (0.34) and the default top_n for over_time (8, max 15), as well as clarifying the subset parameter's differing classification rates. This goes beyond schema 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 computes how a filtered set distributes across precomputed LDA topics, distinguishing it from keyword counting ('use this instead of keyword counting to map a corpus'). It specifies the resource (topic distribution) and the action (distributing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('use this instead of keyword counting to map a corpus') and provides nuanced guidance on the two subsets (articles vs references) with their classification rates. It also clarifies optional parameters like over_time and min_prob.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_audiovisualList audiovisual materialsRead-onlyIdempotentInspect
List audiovisual materials (Nigerian recordings, incl. Hausa/Arabic content).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 50 | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional). The subset is currently all Nigeria |
list_locationsList lieux from the indexRead-onlyIdempotentInspect
List lieux from the IWAC index, sorted by frequency (most-referenced first). The optional 'country' filter selects entries that APPEAR IN records from that country (mentioned-in, not located-in), ranked by collection-wide 'frequency' — so foreign and cross-border entries can appear. Nigeria returns none here (index frequency is computed from articles + publications + references, which have no Nigerian items — Nigeria is audiovisual only).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50, max 200 | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional). Selects lieux MENTIONED IN records from that country, not entities located there |
list_periodicalsList periodicalsRead-onlyIdempotentInspect
List the Islamic periodical/series titles in the publications subset, with issue counts and year ranges. Use the returned newspaper value as the newspaper filter on search_publications.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Togo (accents optional) |
Output Schema
| Name | Required | Description |
|---|---|---|
| view | Yes | |
| periodicals | Yes | |
| country_filter | No | |
| total_periodicals | Yes |
list_personsList personnes from the indexRead-onlyIdempotentInspect
List personnes from the IWAC index, sorted by frequency (most-referenced first). The optional 'country' filter selects entries that APPEAR IN records from that country (mentioned-in, not located-in), ranked by collection-wide 'frequency' — so foreign and cross-border entries can appear. Nigeria returns none here (index frequency is computed from articles + publications + references, which have no Nigerian items — Nigeria is audiovisual only).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50, max 200 | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional). Selects personnes MENTIONED IN records from that country, not entities located there |
list_subjectsList sujets from the indexRead-onlyIdempotentInspect
List sujets from the IWAC index, sorted by frequency (most-referenced first).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50, max 200 | |
| offset | No |
searchSearch IWACRead-onlyIdempotentInspect
Search the Islam West Africa Collection across newspaper articles, Islamic publications, archival documents, academic references, audiovisual recordings, photographs, and the authority index (persons/places/organisations/events/subjects). Pass ONE concept or name — e.g. 'Tijaniyya', 'laïcité', 'Sheikh Gumi', 'pèlerinage'. Matching is accent- and case-insensitive; a multi-word query requires every word to appear somewhere in the item, so prefer a single concept per call. Write query strings and concept keywords in French for press/publication/document/index discovery even when the user's report language is not French. Academic references are multilingual, so try French and English title/abstract terms when relevant; metadata/filter labels remain French. Use the French transliteration of Islamic terms (Tabaski not 'Eid al-Adha', charia not 'sharia', Maouloud not 'Mawlid'). Returns {results:[{id,title,url,category}], ranking}; each result's category names its subset and the ranking field documents the ordering. Pass an id to fetch to read the full text. For filtered queries (by country, date, or newspaper) use the search_* tools instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results across all categories. Default 20, max 50. | |
| query | Yes | One concept, name, or short phrase; use French concept terms for primary sources, and French/English terms for references |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| limit | Yes | |
| ranking | Yes | |
| results | Yes | |
| deep_scan | Yes | |
| limit_warning | No | |
| requested_limit | No | |
| coverage_warning | No | |
| unavailable_categories | No |
search_articlesSearch newspaper articlesRead-onlyIdempotentInspect
Search IWAC newspaper articles by keyword (title + OCR + AI abstract), country, newspaper, subject, and date range. Use French concept keywords regardless of the user's report language. Matching is accent- and case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 100 | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Togo (accents optional) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | French concept keyword; substring match on title, OCR text, and AI abstract | |
| subject | No | ||
| date_from | No | YYYY-MM-DD (or YYYY) | |
| newspaper | No | ||
| with_description | No | Include each article's ~500-char AI abstract (description_ai) for triage without get_article. Adds ~125 tokens/row, so pass a smaller limit (≤10) when enabling it. |
search_audiovisualSearch audiovisual materialsRead-onlyIdempotentInspect
Search audiovisual materials by keyword and metadata. Keyword matches title, creator, publisher, subject, spatial, language, source, and AI description where present.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 50 | |
| medium | No | Exact medium: audio | video (validated) | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional). The subset is currently all Nigeria | |
| keyword | No | Substring match across audiovisual title/metadata fields | |
| subject | No | Exact subject tag | |
| language | No | Exact language value, e.g. Haoussa | Arabe | Anglais |
search_by_sentimentFilter articles by AI sentimentRead-onlyIdempotentInspect
Filter articles by Gemini sentiment labels (accent/case-insensitive exact match).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 100 | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Togo (accents optional) | |
| subject | No | ||
| polarity | No | Très positif | Positif | Neutre | Négatif | Très négatif | Non applicable | |
| centrality | No | Très central | Central | Secondaire | Marginal | Non abordé |
search_documentsSearch archival documentsRead-onlyIdempotentInspect
Search the small archival-documents subset (~26 items: Islamic association reports, flyers, project documents — mostly Burkina Faso). Use French concept keywords regardless of the user's report language. Most have OCR text and an AI description. Call with no arguments to list all.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 15, max 50 | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional). Corpus is mostly Burkina Faso/Togo/Benin | |
| keyword | No | French concept keyword; substring match on title, OCR, AI description and subject (accent-insensitive) |
search_imagesSearch photographsRead-onlyIdempotentInspect
Search the IWAC photographs (30 items: mosques, radio stations, schools, signage and street scenes documented during fieldwork). Keyword matches title, creator, subject, place and the rare caption. Each result carries image_url (the full-resolution file), coordinates ('lat, lng' where known) and the canonical IWAC page. Call with no arguments to list all. Captions are almost never present, so prefer subject/place filters over keywords, or semantic_search_images when it is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 50 | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| creator | No | Photographer name (substring match) | |
| date_to | No | YYYY-MM-DD (or YYYY) | |
| keyword | No | French concept keyword; substring match on title, creator, subject, place and caption | |
| spatial | No | Exact place name, e.g. Ouagadougou (pipe-aware) | |
| subject | No | Exact subject tag (pipe-aware) | |
| date_from | No | YYYY-MM-DD (or YYYY) |
search_indexSearch authority indexRead-onlyIdempotentInspect
Search the IWAC authority index (persons, places, organisations, events, subjects) by name. Accent/case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 100 | |
| offset | No | ||
| keyword | Yes | Search term matched against the entry title | |
| index_type | No | Exact type (accents optional), validated against: Personnes | Lieux | Organisations | Événements | Sujets | Notices d'autorité. An unrecognised value returns an error listing the valid types. |
search_publicationsSearch publicationsRead-onlyIdempotentInspect
Search Islamic publications (periodical issues, books). keyword matches title, subject, table of contents, and full OCR text (TOC hits come back as matching_toc_entries); use French concept keywords regardless of the user's report language. Filter by newspaper/series, subject, country and year. Use list_periodicals to discover series titles, and get_publication_fulltext for keyword excerpts from a single issue.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 100 | |
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Togo (accents optional) | |
| date_to | No | Latest year, YYYY | |
| keyword | No | French concept keyword; substring match on title + subject + table of contents + OCR (accent-insensitive) | |
| subject | No | Subject tag (~87% of issues are tagged) | |
| date_from | No | Earliest year, YYYY | |
| newspaper | No | Periodical/series title (see list_periodicals) |
search_referencesSearch academic referencesRead-onlyIdempotentInspect
Search academic references (journal articles, book chapters, theses, books, reports) by keyword and metadata. keyword is a single substring match over title + abstract, so search ONE term per call (combined terms like 'pèlerinage Mecque' miss results). References are multilingual: try French and English title/abstract keywords when relevant; metadata/filter values such as reference_type and language use French labels. Results include a short abstract snippet — use get_reference for the full abstract and bibliographic detail.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, max 100 | |
| author | No | ||
| offset | No | ||
| country | No | Exact country name: Benin | Burkina Faso | Côte d'Ivoire | Niger | Nigeria | Togo (accents optional) | |
| date_to | No | Latest year, YYYY | |
| keyword | No | One French or English concept keyword; substring match on title + abstract (one term per call, accent-insensitive) | |
| subject | No | Subject tag (sparse: ~27% of references are tagged) | |
| language | No | e.g. Français | Anglais | |
| date_from | No | Earliest year, YYYY | |
| reference_type | No | Substring match. Values: Article de revue | Chapitre de livre | Livre | Mémoire de maitrise | Rapport | Thèse de doctorat | Communication scientifique | Compte rendu de livre | Article d'encyclopédie | Mémoire de licence | Article de blog | Working paper. Use the full label for precision — 'Livre' alone also matches 'Chapitre de livre' and 'Compte rendu de livre'. |
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!