Awwab Qibla & Quiz

Find the Qibla direction

find_qibla

Read-onlyIdempotent

Get the Qibla direction (the direction Muslims face in prayer, toward the Kaaba in Makkah) for a place: the bearing in degrees clockwise from true north, the compass direction, the magnetic bearing and declination, and the distance to the Kaaba. Use this for any question about the Qibla, the prayer direction, or the direction of Makkah (Mecca) or the Kaaba, including a request to show a Qibla compass. The result includes an attribution line and live_compass_url, a page with a phone compass that points at the Kaaba. The place is used only to answer the request. It isn't logged or stored.

Input Schema

Name	Required	Description	Default
`place`	No	The place to find the Qibla from: a city (any city of 15,000+ people, in many languages), with the country if it is ambiguous, e.g. "Karachi", "Hyderabad, India", "القاهرة", or coordinates, e.g. "40.71, -74.00".
`language`	No	The language the user is writing in. Sets the language of the card and of the linked live compass page.

Output Schema

Name	Required	Description
`cardinal`	No
`language`	No	The language the card is shown in, when known
`latitude`	Yes
`sentence`	No
`longitude`	Yes
`place_name`	No
`attribution`	Yes
`distance_km`	Yes
`distance_mi`	No
`bearing_true`	Yes	Degrees clockwise from true north
`cardinal_name`	No
`bearing_magnetic`	No	Degrees clockwise from magnetic north (for a needle compass), today
`live_compass_url`	Yes
`magnetic_declination`	No	Degrees, east positive (WMM2025)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 31, 2026

changedInput schema / properties / language / description

Previous value: -"Optional: language of the live compass page linked in the result. Default en."New value: +"The language the user is writing in. Sets the language of the card and of the linked live compass page."

addedOutput schema / properties / language

Added value: +{
+  "description": "The language the card is shown in, when known",
+  "type": "string"
+}

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / place / description

Previous value: -"The place the user named: a city (any city of 15,000+ people, in many languages), with the country if it is ambiguous, e.g. \"Karachi\", \"Hyderabad, India\", \"القاهرة\", or coordinates they typed, e.g. \"40.71, -74.00\"."New value: +"The place to find the Qibla from: a city (any city of 15,000+ people, in many languages), with the country if it is ambiguous, e.g. \"Karachi\", \"Hyderabad, India\", \"القاهرة\", or coordinates, e.g. \"40.71, -74.00\"."

Changed5 schema fields changedOct 30, 2026

removedInput schema / properties / city

Removed value: -{
-  "description": "City name instead of coordinates, e.g. \"Karachi\", \"Hyderabad, India\", \"القاهرة\", \"Москва\".",
-  "maxLength": 120,
-  "type": "string"
-}

removedInput schema / properties / country

Removed value: -{
-  "description": "Optional country (ISO 3166 code like \"PK\", or English name) to narrow a city name.",
-  "maxLength": 60,
-  "type": "string"
-}

removedInput schema / properties / latitude

Removed value: -{
-  "description": "Latitude in decimal degrees (north positive). Use with longitude.",
-  "maximum": 90,
-  "minimum": -90,
-  "type": "number"
-}

removedInput schema / properties / longitude

Removed value: -{
-  "description": "Longitude in decimal degrees (east positive). Use with latitude.",
-  "maximum": 180,
-  "minimum": -180,
-  "type": "number"
-}

addedInput schema / properties / place

Added value: +{
+  "description": "The place the user named: a city (any city of 15,000+ people, in many languages), with the country if it is ambiguous, e.g. \"Karachi\", \"Hyderabad, India\", \"القاهرة\", or coordinates they typed, e.g. \"40.71, -74.00\".",
+  "maxLength": 120,
+  "type": "string"
+}

First observedOct 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: the privacy guarantee that the place 'isn't logged or stored' and the presence of an attribution line plus a live_compass_url in the result. It stops short of covering failure behavior, such as ambiguous or unknown places.

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

Conciseness4/5

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

Front-loaded with the purpose and the definition before the usage triggers, and each subsequent sentence carries distinct information (outputs, triggers, privacy). It runs slightly long for a two-parameter lookup, with the output enumeration being partly redundant with the output schema, but nothing is filler.

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

Completeness4/5

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

For a simple two-param, annotated, read-only lookup with an output schema, the description covers purpose, triggers, output shape and privacy. The only real gap is edge-case behavior, e.g. what happens when the place is ambiguous or not matched at the 15,000-population threshold.

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%, with both the place format (city, qualified city, coordinates) and the language enum fully documented in-schema, so the baseline is 3. The description adds nothing param-specific beyond noting the place is only used to answer the request, which is a privacy note rather than semantic clarification.

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?

States a specific verb and resource ('Get the Qibla direction') and immediately defines the concept for agents that lack domain knowledge, including the reference point (Kaaba in Makkah). It is unmistakable against the siblings check_answer and start_quiz, which belong to a different domain entirely.

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

Usage Guidelines4/5

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

Enumerates concrete invocation triggers: 'any question about the Qibla, the prayer direction, or the direction of Makkah (Mecca) or the Kaaba, including a request to show a Qibla compass.' There is no explicit when-not or named alternative, but no plausible alternative tool exists in this sibling set, so the guidance is effectively complete.

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

All Awwab Qibla & Quiz tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?