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 |
Changes observed during successful MCP inspections.
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.
Add one secure layer between your agents and this server.
