Skip to main content
Glama
djalal

quran-mcp-server

by djalal

verses-by_page_number

Retrieve Quranic verses by Madani Mushaf page number with optional translations, tafsirs, audio, and word details using the Quran MCP Server API.

Instructions

Get all verses of a specific Madani Mushaf page

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
audioNoId of recitation
fieldsNoComma separated list of ayah fields
languageNoLanguage to fetch word translation
pageNoFor paginating within the result
page_numberYesMadani Mushaf page number (1-604)
per_pageNoRecords per api call
tafsirsNoComma separated ids of tafsirs
translation_fieldsNoComma separated list of translation fields
translationsNoComma separated ids of translations
word_fieldsNoComma separated list of word fields
wordsNoInclude words of each ayah

Implementation Reference

  • The main handler function for the 'verses-by_page_number' tool. Validates input arguments using Zod schema, calls the verses service, logs the response/error, and returns formatted text content or error response.
    /**
     * Handler for the verses-by_page_number tool
     */
    export async function handleVersesByPageNumber(args: any) {
      try {
        // Validate arguments
        const validatedArgs = versesByPageNumberSchema.parse(args);
        
        // Call the service
        const result = await versesService.versesByPageNumber(validatedArgs);
        
        // Log the response in verbose mode
        verboseLog('response', {
          tool: 'verses-by_page_number',
          result
        });
        
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(result, null, 2)
            }
          ]
        };
      } catch (error) {
        verboseLog('error', {
          tool: 'verses-by_page_number',
          error: error instanceof Error ? error.message : String(error)
        });
        
        if (error instanceof z.ZodError) {
          return {
            content: [{ 
              type: "text", 
              text: `Validation error: ${error.errors.map(e => `${e.path.join('.')}: ${e.message}`).join(', ')}`
            }],
            isError: true,
          };
        }
        
        return {
          content: [{ 
            type: "text", 
            text: `Error: ${error instanceof Error ? error.message : "Unknown error"}`
          }],
          isError: true,
        };
      }
  • Zod input schema for the tool, defining required 'page_number' and optional parameters like language, words, translations, audio, pagination, etc.
     * Schema for verses-by_page_number
     */
    export const versesByPageNumberSchema = z.object({
      page_number: z.string().describe("Madani Mushaf page number (1-604)"),
      ...commonVerseParams,
      ...paginationParams,
    });
  • src/server.ts:147-150 (registration)
    Tool registration in the listTools request handler, specifying the tool name, description, and input schema (converted to JSON schema).
      name: ApiTools.verses_by_page_number,
      description: "Get all verses of a specific Madani Mushaf page",
      inputSchema: zodToJsonSchema(versesSchemas.versesByPageNumber),
    },
  • src/server.ts:267-268 (registration)
    Handler dispatch in the callTool request handler, mapping the tool name to the execution of handleVersesByPageNumber.
    case ApiTools.verses_by_page_number:
      return await handleVersesByPageNumber(request.params.arguments);
  • Supporting service method that performs the actual API call to Quran.com API endpoint /verses/by_page/{page_number}, handles validation, and returns structured response.
     * Get verses by page number
     * Get all verses of a specific Madani Mushaf page(1 to 604)
     * 
     * @param {Object} params - The parameters for this operation
     * @returns {Promise<VersesByPageNumberResponse>} The operation result
     * @throws {ApiError} If the operation fails
     */
    async versesByPageNumber(params: z.infer<typeof versesByPageNumberSchema>): Promise<VersesByPageNumberResponse> {
      try {
        // Validate parameters
        const validatedParams = versesByPageNumberSchema.parse(params);
        
        const url = `${API_BASE_URL}/verses/by_page/${validatedParams.page_number}`;
        
        // Make request to Quran.com API
        const data = await makeApiRequest(url, {
          language: validatedParams.language,
          words: validatedParams.words,
          translations: validatedParams.translations,
          audio: validatedParams.audio,
          tafsirs: validatedParams.tafsirs,
          word_fields: validatedParams.word_fields,
          translation_fields: validatedParams.translation_fields,
          fields: validatedParams.fields,
          page: validatedParams.page,
          per_page: validatedParams.per_page
        });
        
        return {
          success: true,
          message: "verses-by_page_number executed successfully",
          data
        };
      } catch (error) {
        verboseLog('error', {
          method: 'versesByPageNumber',
          error: error instanceof Error ? error.message : String(error)
        });
        
        if (error instanceof z.ZodError) {
          throw new ApiError(`Validation error: ${error.errors.map(e => `${e.path.join('.')}: ${e.message}`).join(', ')}`, 400);
        }
        
        // Re-throw other errors
        throw error;
      }
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this is a read-only operation, what format the verses are returned in, whether there are rate limits, authentication requirements, or pagination behavior (despite having 'page' and 'per_page' parameters). The description is minimal and lacks operational context.

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 a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a retrieval tool and front-loads the essential information. Every word earns its place in conveying the tool's primary function.

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

Completeness2/5

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

For a tool with 11 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the relationship between parameters (e.g., how 'audio', 'tafsirs', and 'translations' interact), what the return format looks like, or important behavioral constraints. The agent must rely entirely on the input schema for operational details.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it mentions 'page number' but the schema already describes it as 'Madani Mushaf page number (1-604)'. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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 clearly states the specific action ('Get all verses') and resource ('of a specific Madani Mushaf page'), with the page number range (1-604) providing precise scope. It effectively distinguishes this from sibling tools like 'verses-by_chapter_number' or 'verses-by_juz_number' by specifying the page-based retrieval method.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. While the description implies it's for page-based retrieval, it doesn't mention when page-based access is preferable over chapter-based, juz-based, or other verse retrieval methods available in the sibling tools. The agent must infer usage context from the tool name alone.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/djalal/quran-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server