Community-driven Egyptian Arabic slang dictionary with Arabic and Franco-Arabic search and lookup.
Scored across 8 tools
Each tool has a clearly distinct retrieval purpose: latest, trending, word of the day, related words, exact lookup, search, and metadata listing. An agent can easily tell which tool to use based on the user's intent.
All tools use consistent snake_case with a verb_noun structure (get_*, list_*, lookup_word, search_words). The pattern is predictable and readable throughout.
Eight tools is well-scoped for a read-only slang dictionary API. It covers discovery, search, lookup, and metadata without redundant or extraneous endpoints.
Core dictionary workflows (search, lookup, related words, latest/trending/word-of-day, tag and region listing) are covered. However, list_tags and list_regions are dead ends because no tool retrieves words filtered by a tag or region, which is a minor but noticeable gap.
Get the most recently added Egyptian Arabic slang words on 3ammiya. Useful for seeing what new slang the community is documenting.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (1-25, default 10) | |
| locale | No | Preferred definition language | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys only purpose, not ordering details (e.g., newest-first), pagination behavior, or what the result objects contain, which matters for a list endpoint. For a zero-annotation tool, this is thin.
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 no filler. The purpose is stated first, followed by the use case.
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 a 2-param, no-annotation, no-output-schema list tool, the description covers the essential what and why. The missing pieces are ordering and distinguishing from the closely related sibling tools, which would materially help routing.
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 both limit and locale are fully documented in the schema, including the 1-25 bound and enum values. The description adds nothing beyond the schema, so the baseline 3 applies rather than a lower score.
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 (get) and resource (most recently added Egyptian Arabic slang words) with a clear scope that distinguishes it from siblings like get_trending_words and get_word_of_day. An agent can immediately tell this is a recency-ordered list, not a search or lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is 'useful for seeing what new slang the community is documenting', which implies a discovery use case, but it never explicitly names when to use this versus get_trending_words or get_related_words. The sibling set is highly overlapping, so the absence of an explicit routing rule is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get popular/trending Egyptian Arabic slang words from 3ammiya, ranked by community vote score. Useful for discovering widely-used slang.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (1-25, default 10) | |
| locale | No | Preferred definition language | en |
| period | No | Time period: week, month, or all | week |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose meaningful behavior — results are ranked by community vote score and sourced from 3ammiya — but says nothing about read-only nature, result shape, or how the period interacts with ranking. It adds some value but leaves notable gaps for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and ranking rule, followed by the use case. No wasted words and nothing buried.
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 read-only, zero-required-parameter list tool with full schema coverage and no output schema, the description covers what is returned, how it is ordered, where it comes from, and why to use it. Only minor gaps remain (no sibling routing), so it is nearly 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 description coverage is 100%, so limit, locale, and period are already fully documented in the schema. The description adds no parameter-level detail beyond the implicit notion of a trend window; 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 — popular/trending Egyptian Arabic slang words from 3ammiya — plus the ranking criterion (community vote score). It is distinguishable from siblings like get_latest_words (recency) or lookup_word (single lookup), but it never names a sibling explicitly, 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?
"Useful for discovering widely-used slang" implies the use case but gives no explicit when-to-use vs alternatives (e.g. get_latest_words for newest entries, search_words for targeted queries) and no exclusions. Usage is inferable but left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's featured Egyptian Arabic Word of the Day from 3ammiya. Returns a popular word with its top definition, useful for learning Egyptian slang.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Preferred definition language | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return content (a word with its top definition) and implies a daily-changing featured item, but omits other behavioral details such as caching, timezone for 'today', or error handling.
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 tool's purpose and return value. No wasted words; the final clause about learning Egyptian slang adds brief useful context without bloating the description.
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 one-parameter read tool with no output schema, the description adequately covers purpose and return content. It could mention that the word changes daily or how the locale affects the result, but the schema already handles the locale parameter.
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 single 'locale' parameter with its enum and default is fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema already 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?
States a specific verb ('Get') and resource ('today's featured Egyptian Arabic Word of the Day from 3ammiya'), clearly identifying the tool's scope. It implicitly distinguishes itself from siblings like get_latest_words and get_trending_words by being the daily featured word, though it does not name any alternative explicitly.
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 no explicit when-to-use or when-not-to-use guidance. The phrase 'useful for learning Egyptian slang' gives a general context but does not route the agent among siblings such as lookup_word, search_words, or get_trending_words.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Egyptian dialect regions in the 3ammiya dictionary. Regions indicate where a word is commonly used (e.g., Cairo, Alexandria, Upper Egypt).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a static reference taxonomy of regions with examples (Cairo, Alexandria, Upper Egypt), which is genuinely useful, but it omits ordering, completeness, and the fact that it takes no arguments.
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 tight sentences, front-loaded with the core action and scope, followed by a brief semantic gloss on what a region means. No filler, no 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?
For a zero-parameter taxonomy list with no output schema, the description supplies the essential context (domain, dictionary, meaning of a region, examples). Only the return shape (plain strings vs. region objects) is left unstated, which is a minor 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?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing in the schema for the description to clarify or compensate for.
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 (List) and resource (Egyptian dialect regions) and scopes it to the 3ammiya dictionary, adding that regions denote where a word is used. It is clearly distinct from siblings like search_words or list_tags, though it never names a sibling to disambiguate explicitly.
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: the second sentence ('Regions indicate where a word is commonly used') hints at why an agent would want this taxonomy, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool for region-based filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all topic categories (tags) available in the 3ammiya dictionary. Tags categorize words by theme (e.g., food, greetings, insults).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. The verb 'List' implies a safe read operation and the dictionary scope is stated, but nothing is said about whether the tag set is static or changing, whether it is exhaustive, or whether any auth applies.
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 tight sentences: the action and scope are front-loaded, and the second sentence adds the definitional context an agent needs. Nothing is wasted or repeated from 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 no output schema, the description does the necessary work of telling the agent the return is a set of topic categories, with examples. It is nearly complete for such a simple tool, missing only a note on the list's stability or completeness.
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; the baseline of 4 applies. The description's parenthetical examples add flavor about the value space but no parameter meaning is required.
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 ('List all topic categories (tags)') and scopes it to the 3ammiya dictionary, so the agent knows exactly what comes back. It does not, however, name or contrast itself with the closest sibling, list_regions, which is also a zero-param enumeration tool.
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 explains what tags are ('categorize words by theme') but never says when to call this tool versus list_regions or search_words, nor any prerequisite. Usage is only faintly implied by the examples given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full dictionary entry for a specific Egyptian Arabic word by its URL slug. Returns all live definitions with examples, vote scores, tags, and region. Use search_words first if you don't know the exact slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The word's URL slug (e.g., 'kelma' or 'عامية') | |
| locale | No | Preferred definition language; original-language fallbacks are labeled | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does real work: it discloses that only 'live' definitions are returned (implying unpublished/removed entries are filtered), and enumerates the returned fields (examples, vote scores, tags, region). It says nothing about auth requirements or rate limits, but the read-only nature is unambiguous from 'Get'.
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, zero waste: the lookup semantic and its input are front-loaded, and the alternative-tool hint is relegated to the end where it belongs. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must describe returns, and it does so at a useful level of abstraction (definitions plus examples, votes, tags, region). Combined with the search_words fallback, an agent has what it needs to call this correctly; only edge cases like missing slugs are 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 description coverage is 100% – both the slug format and the locale enum/default are already documented, including the detail that original-language fallbacks are labeled. The description only restates that lookup is by slug, adding no syntax or format detail 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 ('Get'), a specific resource ('full dictionary entry'), and the exact key the entry is addressed by ('URL slug'), scoped to Egyptian Arabic. It also enumerates what the entry contains, so an agent can immediately distinguish it from the list/search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit routing rule: 'Use search_words first if you don't know the exact slug.' This names the alternative sibling and the condition under which it should be preferred over this tool, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 3ammiya Egyptian Arabic slang dictionary. Accepts Arabic script (عامية), Franco-Arabic (3ammiya), or English (slang). Franco-Arabic numerals (2=ء, 3=ع, 5=خ, 7=ح) are normalized automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (1-25, default 10) | |
| query | Yes | Search query in Arabic, Franco-Arabic, or English | |
| locale | No | Preferred definition language; original-language fallbacks are labeled | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add genuinely useful behavior: automatic normalization of Franco-Arabic numerals (2=ء, 3=ع, 5=خ, 7=ح) and multi-script acceptance. It stops short of disclosing result behavior, matching strategy (exact/fuzzy), or any rate/limit context, so it is only partially transparent.
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 tight sentences, front-loaded with the resource scope and followed by the input-format rules. No filler, no repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema and no annotations, the input side is well covered, but nothing is said about the shape of results (definitions, labels, count vs limit interaction) or whether matching is exact or partial. An agent can call it, but cannot predict the response.
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 earns an extra point by explaining how the query parameter is interpreted in practice, including the numeral-to-letter mapping, which the schema's brief 'Arabic, Franco-Arabic, or English' note does not. It adds nothing for limit or locale.
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 gives a specific verb+resource: searching the '3ammiya Egyptian Arabic slang dictionary', which is a narrower and more informative scope than the name alone. It does not, however, distinguish this from the sibling lookup_word or get_related_words, so an agent must infer the search-vs-lookup boundary.
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 implied by the input-format guidance (Arabic, Franco-Arabic, or English), but there is no explicit when-to-use versus lookup_word for an exact match, nor any statement of exclusions or prerequisites. Adequate but leaves routing to inference.
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.
get_latest_wordsget_related_wordsget_trending_wordsget_word_of_daylist_regionslist_tagslookup_wordsearch_wordsBilingual dictionary lookup and translation validation for kasahorow Fellows.
Sourced internet slang and usage, including labeled non-graphic adult vocabulary.
Search and read Lebanese laws, articles, court rulings and the Official Gazette, verbatim.
Build dictionaries & glossaries with AI: entries, senses, versions, print PDF, EPUB, web reader, RTL
Add one secure layer between your agents and this server.
