mcpbase
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_datetimeA | Current date and time in an IANA timezone, optionally shifted by whole days. The iso field is the wall clock in that zone, so its offset makes the instant unambiguous; unix is the same instant as epoch seconds, and human is a localized rendering. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of misselection or overlapping purpose. Its purpose (returning the current datetime in a given timezone) is clearly stated.
A single tool using a clean verb_noun snake_case name (get_datetime). No inconsistency is possible with one tool.
The server is scoped narrowly to datetime retrieval, so one tool is defensible, but the surface is very thin. A single trivial operation sits at the borderline of usefulness for an MCP server.
It handles the core case (current time in an IANA zone, with day offsets and multiple renderings), but there is no parsing, conversion between zones, duration/diff, or formatting tool. Agents needing anything beyond 'now' will hit a dead end.