Skip to main content
Glama
stefanveliki

Vreme Temporal MCP

by stefanveliki
OverviewSchemaRelated ServersScoreDiscussions
Remote

Vreme Temporal MCP

Temporal intelligence for AI assistants

Give your AI assistant rich temporal awareness — timezone intelligence, cultural calendars, astronomical events, and time-sensitive context.

Works with Cursor, VS Code, Claude Desktop, Continue, Cline, and any MCP-compatible client.

npm version License: MIT

What This Does

Instead of just knowing what time it is, your AI gets rich temporal context:

You: "What time is it in Tokyo?"

Claude: "Sunday, November 30, 2025 at 1:36 PM JST. Sunset in 2 hours 51 minutes.

🌅 Sunrise: 6:31 AM
🌇 Sunset: 4:28 PM  
🌙 Moon: Full Moon (70% illuminated)

📅 Hebrew: 10 Kislev 5786
📅 Islamic: 9 Jumada al-Thani 1447 AH
📅 Chinese: Year 2025, Month 10, Day 11 (Metal Snake)

⏰ Weekend - Not appropriate for work calls"

Related MCP server: MCP Time Server Node

Features

  • 🌍 200+ Timezones - All pytz timezones with DST handling

  • 📅 9 Cultural Calendars - Hebrew, Islamic, Chinese, Hindu, Persian, Buddhist, Bahá'í, Ethiopian, Mayan

  • 🕌 Islamic Prayer Times - All 5 daily prayers with qibla direction

  • 🌅 Astronomical Events - Sunrise, sunset, moon phases, twilight times

  • ✅ Activity Appropriateness - Smart recommendations for calls, meetings, work

  • 🍽️ Religious Observances - Fasting detection, work restrictions, holiday awareness

  • 💬 Natural Language - No rigid schemas, just ask naturally

Installation

npm install -g @vreme/temporal-mcp

Configuration

Add to your MCP client configuration:

Claude Desktop:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "vreme": {
      "command": "vreme-temporal-mcp"
    }
  }
}

Continue / Cline:

Add to your MCP configuration following their respective setup guides.

Restart your AI client and you're ready!

Example Queries

Time & Timezones

  • "What time is it in Tokyo?"

  • "Current time in New York"

  • "What timezone is Paris in?"

Cultural Intelligence

  • "Is it Shabbat in Jerusalem?"

  • "Is it Ramadan?"

  • "When is Chinese New Year?"

  • "What's the Hebrew date today?"

  • "When is Diwali 2025?"

Activity Appropriateness

  • "Is it a good time to call someone in Tokyo?"

  • "Can I email someone in Jerusalem right now?"

  • "Should I call Berlin now?"

Astronomical Data

  • "What time is sunrise in Tokyo?"

  • "When does the sun set in Paris?"

  • "What's the moon phase?"

Prayer Times

  • "What are prayer times in Dubai?"

  • "When is Fajr in Istanbul?"

  • "Prayer times in New York"

Time Until

  • "How long until sunset?"

  • "Time until sunrise in Berlin"

How It Works

The MCP server connects your AI client to the Vreme Time API, which provides:

  1. Natural language parsing - Understands your questions

  2. Timezone calculations - Accurate time conversions

  3. Cultural calendar conversions - 9 calendar systems

  4. Astronomical computations - Sunrise, sunset, moon data

  5. Activity analysis - Cultural and temporal appropriateness

All responses include full temporal context, not just clock time.

Architecture

AI Client (Claude Desktop / Continue / Cline)
    ↓ (MCP Protocol)
@vreme/temporal-mcp
    ↓ (HTTPS)
api.vreme.ai
    ↓
Temporal Intelligence Engine

  • Stateless - No data stored, pure computation

  • Fast - <500ms response time (95th percentile)

  • Reliable - Built on battle-tested libraries (pytz, astral, hijri-converter)

Supported Features

Cultural Calendars (9)

  • Hebrew (with holiday detection)

  • Islamic (with Ramadan, prayer times)

  • Chinese (lunisolar, zodiac animals)

  • Hindu (festival dates)

  • Persian (Nowruz, etc.)

  • Buddhist (Vesak, observances)

  • Bahá'í (calendar system)

  • Ethiopian (unique calendar)

  • Mayan (long count)

Prayer Times

  • All 5 daily prayers (Fajr, Dhuhr, Asr, Maghrib, Isha)

  • Multiple calculation methods (MWL, ISNA, Egypt, Makkah, Karachi, Tehran, Jafari)

  • Qibla direction to Mecca

  • Next prayer countdown

Religious Observances

  • Shabbat detection and times

  • Ramadan fasting hours

  • Jewish holidays and restrictions

  • Work permission status

  • Fasting day detection

Troubleshooting

MCP Server Not Appearing

  • Verify installation: which vreme-temporal-mcp

  • Check your client's config file syntax (valid JSON)

  • Completely restart your AI client (quit and reopen)

Connection Issues

  • Requires internet access (queries api.vreme.ai)

  • Check API status: curl https://api.vreme.ai/health

  • Firewall/VPN may be blocking

Query Errors

  • Try major city names first

  • Use simple queries: "What time is it in London?"

  • Some obscure locations may not be recognized

API

This MCP server is powered by the public Vreme Time API.

Endpoint: https://api.vreme.ai/query

You can also use the API directly:

curl -X POST https://api.vreme.ai/query \
  -H "Content-Type: application/json" \
  -d '{"query": "What time is it in Tokyo?"}'

Links

License

MIT License - Free and open source forever.

About Vreme

Vreme (Bulgarian: "time") is building temporal intelligence for AI. This time service is the first product — validating the architecture for our upcoming temporal memory service.

Time, understood. Your AI knows what time it is anywhere, respects cultural calendars, and understands contextual appropriateness.

Memory, preserved. Coming Q2 2026: Your AI remembers every conversation, every insight, every step of your learning journey.

Questions? hello@vreme.ai

Built with ❤️ for temporal awareness

Available Tools

3 tools
check_activity_appropriatenessA

Check if the current time is appropriate for specific activities (calls, work, meetings) in a given location. Takes into account time of day, cultural/religious observances across 9 calendar systems (Shabbat, Ramadan fasting, religious holidays from Hebrew, Islamic, Hindu, Buddhist, and other traditions), work restrictions, and local customs. Perfect for 'Can I call someone in X?' or 'Is it a good time to contact Y?' queries.

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesLocation name (e.g., 'Berlin', 'Jerusalem', 'Tokyo')
activityNoOptional: Type of activity to check ('call', 'work', 'meeting'). If omitted, checks all activities.
user_timezoneNoOptional: Your timezone for relative time calculations

TDQS

A3.8/5.0
Behavior3/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 describes what the tool considers (time of day, cultural/religious observances, work restrictions, local customs) but lacks details on output format, error handling, or data sources. This is adequate but has gaps for a tool with complex logic.

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?

The description is appropriately sized and front-loaded, starting with the core purpose and following with details and examples. Every sentence adds value, though it could be slightly more concise by integrating the examples more tightly.

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

Completeness3/5

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

Given the tool's complexity (multiple cultural systems) and lack of annotations/output schema, the description is moderately complete. It covers the scope and inputs well but does not explain the return values or potential limitations, which is a gap for a decision-making tool.

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 parameters. The description adds context by explaining the activity parameter checks 'calls, work, meetings' and implies broader cultural considerations, but does not provide additional syntax or format details beyond what the schema provides.

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 tool's purpose with specific verbs ('check if the current time is appropriate') and resources ('activities in a given location'), distinguishing it from sibling tools like query_prayer_times and query_time by focusing on appropriateness rather than raw time data. It provides concrete examples of activities and use cases.

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?

The description explicitly states when to use this tool with examples like 'Can I call someone in X?' or 'Is it a good time to contact Y?', providing clear context. However, it does not specify when not to use it or explicitly differentiate from alternatives like query_time for basic time queries.

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

query_prayer_timesA

Get Islamic prayer times (Salah/Namaz) for any location. Returns all 5 daily prayers (Fajr, Dhuhr, Asr, Maghrib, Isha), next prayer time, and Qibla direction to Mecca. Calculation method is automatically selected based on location (MWL, ISNA, Egypt, Makkah, Karachi, Tehran, Jafari). Supports queries for specific prayers or all prayers.

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesLocation name (e.g., 'Dubai', 'Istanbul', 'New York', 'London')
prayerNoOptional: Specific prayer to query ('fajr', 'dhuhr', 'asr', 'maghrib', 'isha'). If omitted, returns all prayers.

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden and discloses key behavioral traits: it returns all 5 daily prayers, next prayer time, Qibla direction, and automatically selects calculation methods. However, it lacks details on error handling, rate limits, or authentication needs.

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 appropriately sized and front-loaded, with two efficient sentences that cover purpose, returns, calculation methods, and query options without any wasted words, making it easy for an agent to parse quickly.

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

Completeness3/5

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

Given the tool's moderate complexity, no annotations, and no output schema, the description is somewhat complete but has gaps: it explains what the tool does and parameters, but lacks details on output format, error cases, or behavioral constraints like rate limits, which could hinder agent usage.

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 both parameters well. The description adds marginal value by explaining that omitting 'prayer' returns all prayers, but does not provide additional syntax or format details beyond what the schema specifies.

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 tool's purpose with specific verbs ('Get Islamic prayer times') and resources ('for any location'), and distinguishes it from siblings by specifying it returns prayer times, Qibla direction, and uses calculation methods, unlike generic time or appropriateness checking tools.

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?

The description provides clear context for when to use this tool (to get Islamic prayer times) and implies usage by mentioning support for specific prayers or all prayers, but does not explicitly state when not to use it or name alternatives among siblings.

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

query_timeA

Query temporal information using natural language. Get current time, timezone info, 9 cultural calendars (Hebrew, Islamic, Chinese, Hindu, Persian, Buddhist, Bahá'í, Ethiopian, Mayan), astronomical events, religious fasting status, work restrictions, and activity appropriateness for any location. Supports queries like 'What time is it in Tokyo?', 'Is it a good time to call Berlin?', 'Is it Shabbat in Jerusalem?', 'When is sunrise in Paris?', 'Is it Ramadan?', etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNatural language temporal query (e.g., 'What time is it in Tokyo?', 'Is it a good time to call Berlin?', 'Is it Ramadan?', 'When is sunrise in Paris?')
user_timezoneNoOptional: Your timezone for relative time calculations (e.g., 'America/Los_Angeles', 'Europe/London')

TDQS

A3.9/5.0
Behavior3/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 does well by listing the broad capabilities (9 cultural calendars, astronomical events, religious fasting status, etc.) and providing example queries that demonstrate the tool's scope. However, it doesn't mention limitations like rate limits, authentication needs, or what happens with ambiguous queries, leaving some behavioral aspects unclear.

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?

The description is appropriately sized and front-loaded with the core purpose in the first sentence, followed by specific capabilities and example queries. Every sentence adds value, though it could be slightly more concise by combining some capability listings. The structure effectively communicates the tool's scope without unnecessary repetition.

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?

Given the tool's complexity (handling 9 cultural calendars, astronomical events, religious fasting, etc.) with no annotations and no output schema, the description does well by comprehensively listing capabilities and providing example queries. However, it doesn't explain what the return values look like or address potential limitations, leaving some gaps for a tool with such broad functionality.

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 fully documents both parameters. The description adds value by providing multiple concrete examples of valid 'query' parameter values ('What time is it in Tokyo?', 'Is it a good time to call Berlin?', etc.), but doesn't add meaning beyond what the schema provides for the 'user_timezone' parameter. Baseline 3 is appropriate when schema does the heavy lifting.

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 tool's purpose: 'Query temporal information using natural language' followed by a comprehensive list of capabilities including current time, timezone info, 9 cultural calendars, astronomical events, religious fasting status, work restrictions, and activity appropriateness. It distinguishes from siblings by covering a broader temporal scope than 'check_activity_appropriateness' and 'query_prayer_times'.

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?

The description provides clear context for when to use this tool through multiple example queries ('What time is it in Tokyo?', 'Is it a good time to call Berlin?', etc.), showing it handles diverse temporal questions. However, it doesn't explicitly state when NOT to use it or when to prefer sibling tools like 'check_activity_appropriateness' or 'query_prayer_times' for more specific needs.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation2/5

The tools have significant overlap, particularly between 'check_activity_appropriateness' and 'query_time', as both handle activity appropriateness, cultural/religious observances, and work restrictions. 'query_prayer_times' is more distinct but still overlaps with the Islamic calendar aspects of the other tools, leading to potential confusion for an agent trying to select the right tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, using clear verbs like 'check', 'query', and 'query' again. The naming is predictable and readable, with no deviations in style or convention across the three tools.

Tool Count3/5

With only 3 tools, the server feels thin for its broad scope covering temporal information, cultural calendars, religious observances, and activity appropriateness. This limited set may not fully support complex workflows, as agents might need more specialized tools for distinct aspects like calendar conversions or event tracking.

Completeness2/5

The tool surface has significant gaps for the inferred domain of temporal and cultural information. For example, there are no tools for creating or updating calendar events, converting between different calendar systems, or managing user-specific preferences. The existing tools provide querying capabilities but lack lifecycle operations, making the server incomplete for comprehensive temporal management tasks.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Time MCP Server

    ampcome-mcps
    A
    license
    B
    quality
    D
    maintenance
    Gives large language models time awareness capabilities through various time-related functions including current time retrieval, timezone conversion, and relative time calculations.
    6
    1,823
    MIT

  • MCP Time Server Node

    pshempel
    A
    license
    A
    quality
    D
    maintenance
    Provides comprehensive time manipulation capabilities including timezone conversions, date arithmetic, business day calculations, duration calculations, and recurring event handling. Enables natural language time queries with high performance and intelligent caching.
    11
    3
    MIT

  • Chrono MCP

    JMoak
    A
    license
    A
    quality
    B
    maintenance
    Provides comprehensive date, time, timezone, and calendar operations powered by Luxon, enabling AI agents to perform time calculations, timezone conversions, and temporal data handling across 400+ IANA timezones.
    2
    24
    MIT

  • Date MCP Server

    ainarsklavins
    A
    license
    A
    quality
    Not graded
    maintenance
    Provides AI assistants with real-time date, time, and timezone information, enabling them to access current temporal data, format dates, calculate day of week, and work with different timezones.
    4
    7

Appeared in Searches

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/stefanveliki/temporal-mcp'

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