Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@date-today-mcp what's today's date in ISO format?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Ein einfacher MCP-Server mit STDIO-Transport, der das aktuelle Datum in verschiedenen Formaten zurückgibt.
npm install
npm run buildRelated MCP server: mcp-datetimeday
# Server starten (lauscht auf STDIO)
npm start
# Entwicklungsmodus mit automatischem Neustart
npm run devFüge in deiner MCP-Konfigurationsdatei (cline_mcp_settings.json oder ähnlich) hinzu:
{
"mcpServers": {
"date-today": {
"command": "node",
"args": ["/pfad/zum/projekt/date-today-mcp/dist/index.js"]
}
}
}Oder für den Entwicklungsmodus direkt mit tsx:
{
"mcpServers": {
"date-today": {
"command": "npx",
"args": ["tsx", "/pfad/zum/projekt/date-today-mcp/src/index.ts"]
}
}
}Hinweis zu STDIO: Der Server kommuniziert über stdin/stdout per JSON-RPC. Es darf nichts auf stdout geschrieben werden, deshalb erfolgt das Logging ausschließlich auf stderr.
Gibt das aktuelle Datum zurück mit konfigurierbarem Format.
Parameter | Typ | Standard | Beschreibung |
format | string | "european" | Datumsformat |
european - 04.06.2026 (Standard)
iso - 2026-06-04
us - 06/04/2026
full - Thursday, 04. June 2026
short - 4.6.2026
long - 04. June 2026
{
"name": "get_today_date",
"arguments": {
"format": "european"
}
}{
"date": "04.06.2026",
"format": "european",
"timezone": "Asia/Bangkok",
"timestamp": "2026-06-04T10:20:40.278Z"
}# date-today-mcp
# date-today-mcpGibt das aktuelle Datum zurück. Unterstützte Formate: european (DD.MM.YYYY), iso (YYYY-MM-DD), us (MM/DD/YYYY), full (Weekday, DD. Month YYYY), short (D.M.YYYY), long (DD. Month YYYY).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Datumsformat | european |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states it returns the current date and lists formats, but does not explicitly disclose read-only nature, timezone behavior, or any system dependency. However, the operation is inherently non-destructive and the description is not misleading.
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?
The description is a single sentence front-loaded with the main verb and resource. The format list is necessary and concisely presented with inline examples, earning its place without redundancy.
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?
For a simple tool with one optional parameter and no output schema, the description covers all necessary information: the purpose, the parameter's allowed values, and their meaning. No additional context is required.
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?
The schema provides the enum values, but the description adds significant meaning by mapping each enum to its exact date pattern (e.g., 'european (DD.MM.YYYY)', 'iso (YYYY-MM-DD)'). This goes beyond the schema's minimal description 'Datumsformat'.
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?
The description clearly states the tool's function: 'Gibt das aktuelle Datum zurück' (returns the current date). It lists all supported formats, which provides specific and unambiguous resource scope.
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?
The description implies the usage context: use this tool whenever you need the current date. There are no sibling tools or alternatives, so it cannot provide exclusions or comparisons, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of confusion or overlap between tools. The purpose is clear and unambiguous.
The single tool name 'get_today_date' follows a clear verb_noun pattern, which is internally consistent and self-explanatory.
The server has only one tool, which feels thin for a typical MCP server. However, the narrow purpose of returning today's date is fully served by this single tool, making it a borderline case.
The tool fully covers the domain of retrieving today's date with multiple format options. There are no obvious gaps, as the server's stated purpose is strictly date retrieval.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only developer, date, finance, and text utilities. Authless remote MCP server by Clean.tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/damianhunziker/date-today-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
