Skip to main content
Glama
2yousefreda

Islamic Content MCP Server

by 2yousefreda
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

risalat_al_haramain

Retrieve official fatwas, Friday sermons, and hadeeths from the Two Holy Mosques in Mecca and Medina. Access institutional Haramain content with translations and search capabilities.

Instructions

Access Risalat Al-Haramain to fetch official Haramain (Two Holy Mosques) fatwas, Friday sermons, specific hadeeths, and institutional contents. Specializes in official decrees and sermons originating from Mecca and Medina, distinguishing it from general libraries.

Behavior: Read-only. Idempotent. Public endpoints have no auth. Lookup endpoints require apiKey. Handles rate limits via graceful empty returns. Usage Guidelines:

  • Use for Friday sermons from the Haramain, official fatwas from Haramain scholars, or institutional news.

  • Do NOT use for general Islamic books (use islamhouse_library). Action Mapping:

  • get_full_contents, get_contents: language, lang -> Returns { data: [{ id, title, date }] }

  • get_fatwas, get_hadeeths, get_quran: language, lang, [isFeatured (0/1)] -> Returns { data: [{ id, content }] }

  • get_content: id (int), language -> Returns { id, title, body, mediaUrls: [] }

  • search_contents, search_name: query/name (string), language -> Returns { results: [{ id, title }] }

  • get_available_languages, get_content_translation: id (int), language, targetLanguage (ISO-639-1) -> Returns { translations: [] }

  • get_lookups_languages, get_lookups_content_types: language, [apiKey] -> Returns { lookups: [] } Returns: Concrete JSON object { data: [], lookups: [], results: [] } for Haramain official releases.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
langNo
nameNo
queryNo
actionYesRequired. One of: 'get_full_contents', 'get_contents', 'get_content', 'search_name', 'search_contents', 'get_available_languages', 'get_content_translation', 'get_fatwas', 'get_hadeeths', 'get_quran', 'get_lookups_languages', 'get_lookups_content_types'
apiKeyNo
languageNo
isFeaturedNo
targetLanguageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.1.12
    • removedInput schema / properties / apiKey / description
      Removed value: -"API Key for lookup endpoints"
    • removedInput schema / properties / id / description
      Removed value: -"Content ID"
    • removedInput schema / properties / isFeatured / description
      Removed value: -"Featured flag (0 or 1)"
    • removedInput schema / properties / lang / description
      Removed value: -"Secondary language code (ISO-639-1)"
    • removedInput schema / properties / language / description
      Removed value: -"Language code (ISO-639-1)"
    • removedInput schema / properties / name / description
      Removed value: -"Search name"
    • removedInput schema / properties / query / description
      Removed value: -"Search query string"
    • removedInput schema / properties / targetLanguage / description
      Removed value: -"Target translation language (ISO-639-1)"
  2. Changed8 schema fields changedv1.1.11
    • addedInput schema / properties / apiKey / description
      Added value: +"API Key for lookup endpoints"
    • addedInput schema / properties / id / description
      Added value: +"Content ID"
    • addedInput schema / properties / isFeatured / description
      Added value: +"Featured flag (0 or 1)"
    • addedInput schema / properties / lang / description
      Added value: +"Secondary language code (ISO-639-1)"
    • addedInput schema / properties / language / description
      Added value: +"Language code (ISO-639-1)"
    • addedInput schema / properties / name / description
      Added value: +"Search name"
    • addedInput schema / properties / query / description
      Added value: +"Search query string"
    • addedInput schema / properties / targetLanguage / description
      Added value: +"Target translation language (ISO-639-1)"
  3. Addedv1.1.2

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and succeeds: 'Read-only. Idempotent. Public endpoints have no auth. Lookup endpoints require apiKey. Handles rate limits via graceful empty returns.' It also gives expected return object shapes per action family, which is critical behavioral context for a multi-action tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: purpose, behavior, usage guidelines, action mapping, and return shapes. The structure uses clear labels and front-loads the most important information, making it easy for an agent to scan and act.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 actions, 9 parameters, no output schema, and no annotations, this description is unusually complete. It maps every action family to its expected return shape, covers auth and rate-limit behavior, and includes explicit alternative routing. Nothing essential for correct selection or invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 11%, so the description must compensate, and it does comprehensively. The action mapping defines which parameters apply to which actions, notes `language`/`lang` aliases, marks `isFeatured` as `0/1`, describes `targetLanguage` as ISO-639-1, and specifies parameter types such as `id` (int). This adds meaning far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action ('fetch official Haramain fatwas, Friday sermons, specific hadeeths, and institutional contents') and a clear resource scope: Mecca and Medina. It explicitly distinguishes itself from general libraries, so an agent can separate it from siblings without inspecting further.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use the tool ('Use for Friday sermons from the Haramain, official fatwas...') and when not to use it ('Do NOT use for general Islamic books'), naming the exact alternative tool (`islamhouse_library`). This is the strongest possible usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools