Skip to main content
Glama
pshempel

MCP Time Server Node

by pshempel

add_time

Add a specified duration to any date or time. Calculate future dates by adding years, months, days, hours, minutes, or seconds to a base time with timezone support.

Instructions

Add duration to a date/time

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeYesBase time
amountYesAmount to add
unitYesUnit of time
timezoneNoTimezone for calculation (default: system timezone)

Implementation Reference

  • Main handler function for the 'add_time' tool. Parses input time, validates parameters, adds the specified amount of time using date-fns, formats the result with timezone awareness, and applies caching.
    export function addTime(params: AddTimeParams): AddTimeResult {
      debug.timing('addTime called with params: %O', params);
      const { time, amount, unit } = params;
    
      // Validate date input with strict type checking
      validateDateInput(time, 'time');
    
      const config = getConfig();
      const timezone = resolveTimezone(params.timezone, config.defaultTimezone);
    
      // Use withCache wrapper instead of manual cache management
      return withCache(`add_${time}_${amount}_${unit}_${timezone}`, CacheTTL.CALCULATIONS, () => {
        // Validate unit
        validateUnit(unit);
    
        // Validate amount
        validateAmount(amount);
    
        // Validate timezone if provided
        if (params.timezone && !validateTimezone(timezone)) {
          debug.error('Invalid timezone: %s', timezone);
          throw new TimezoneError(`Invalid timezone: ${timezone}`, timezone);
        }
    
        // Parse the input date with timezone handling
        const parseResult = parseDateWithTimezone(time, timezone, params.timezone);
        const { date: inputDate } = parseResult;
    
        // Perform the addition
        // eslint-disable-next-line security/detect-object-injection -- Unit validated earlier
        const addFunction = unitFunctions[unit];
        const resultDate = addFunction(inputDate, amount);
    
        // Format the result
        const output = formatAddTimeResult(inputDate, resultDate, time, params, parseResult);
    
        debug.timing('addTime returning: %O', output);
        return output;
      });
    }
  • TypeScript interfaces defining AddTimeParams (input) and AddTimeResult (output) for the add_time tool.
    export interface AddTimeParams {
      time: string;
      amount: number;
      unit: TimeUnit;
      timezone?: string;
    }
    
    export type SubtractTimeParams = AddTimeParams;
    
    export interface TimeCalculationResult {
      original: string;
      result: string;
      unix_original: number;
      unix_result: number;
    }
    
    // Type alias for consistency with test
    export type AddTimeResult = TimeCalculationResult;
    export type SubtractTimeResult = TimeCalculationResult;
  • src/index.ts:73-92 (registration)
    MCP tool registration definition for 'add_time', including name, description, and input schema used for tools/list response.
    {
      name: 'add_time',
      description: 'Add duration to a date/time',
      inputSchema: {
        type: 'object' as const,
        properties: {
          time: { type: 'string' as const, description: 'Base time' },
          amount: { type: 'number' as const, description: 'Amount to add' },
          unit: {
            type: 'string' as const,
            enum: ['years', 'months', 'days', 'hours', 'minutes', 'seconds'],
            description: 'Unit of time',
          },
          timezone: {
            type: 'string' as const,
            description: 'Timezone for calculation (default: system timezone)',
          },
        },
        required: ['time', 'amount', 'unit'],
      },
  • src/index.ts:262-262 (registration)
    Handler mapping in TOOL_FUNCTIONS that connects the 'add_time' tool name to the addTime implementation function.
    add_time: (params: unknown) => addTime(params as Parameters<typeof addTime>[0]),
  • Key helper function for formatting the add_time results, handling various input formats like Unix timestamps, explicit offsets, and Z suffixes.
    export function formatAddTimeResult(
      inputDate: Date,
      resultDate: Date,
      time: string,
      params: AddTimeParams,
      parseInfo: ParseDateResult
    ): FormatResult {
      debug.timing('formatAddTimeResult called with dates and parseInfo: %O', parseInfo);
    
      const { displayTimezone, hasExplicitOffset, explicitOffset } = parseInfo;
    
      // Handle Unix timestamp formatting
      if (/^\d+$/.test(time)) {
        return formatUnixTimestampResult(inputDate, resultDate, params.timezone ?? undefined);
      }
    
      // Handle explicit offset formatting
      if (hasExplicitOffset) {
        return formatWithExplicitOffset(inputDate, resultDate, time, explicitOffset);
      }
    
      // Handle Z suffix with timezone override
      if (time.includes('Z') && params.timezone) {
        debug.timing('Formatting Z suffix with requested timezone: %s', displayTimezone);
        return {
          original: formatInTimeZone(inputDate, displayTimezone, "yyyy-MM-dd'T'HH:mm:ss.SSSXXX"),
          result: formatInTimeZone(resultDate, displayTimezone, "yyyy-MM-dd'T'HH:mm:ss.SSSXXX"),
          unix_original: Math.floor(inputDate.getTime() / 1000),
          unix_result: Math.floor(resultDate.getTime() / 1000),
        };
      }
    
      // Handle Z suffix without timezone override (UTC)
      if (time.includes('Z')) {
        debug.timing('Formatting Z suffix as UTC');
        return {
          original: inputDate.toISOString(),
          result: resultDate.toISOString(),
          unix_original: Math.floor(inputDate.getTime() / 1000),
          unix_result: Math.floor(resultDate.getTime() / 1000),
        };
      }
    
      // Default formatting with specified timezone
      debug.timing('Formatting in timezone: %s', displayTimezone);
      return {
        original: formatInTimeZone(inputDate, displayTimezone, "yyyy-MM-dd'T'HH:mm:ss.SSSXXX"),
        result: formatInTimeZone(resultDate, displayTimezone, "yyyy-MM-dd'T'HH:mm:ss.SSSXXX"),
        unix_original: Math.floor(inputDate.getTime() / 1000),
        unix_result: Math.floor(resultDate.getTime() / 1000),
      };
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('add duration') but doesn't cover critical aspects like error handling (e.g., invalid inputs), timezone handling details beyond the schema's default note, or output format. This is inadequate for a mutation tool with zero annotation coverage.

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 ('Add duration to a date/time') that is front-loaded and wastes no words. It directly conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.

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?

Given the tool's complexity (a mutation with 4 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain the result (e.g., returns a new datetime), error conditions, or how it differs from siblings, leaving gaps that could hinder correct 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 all parameters (time, amount, unit, timezone) with descriptions and an enum for 'unit'. The description adds no additional meaning beyond what the schema provides, such as examples or edge cases, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Add duration to a date/time' clearly states the verb ('add') and resource ('duration to a date/time'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'subtract_time' or 'calculate_duration', which would require more specificity to earn a 5.

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?

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'subtract_time', 'calculate_duration', and 'convert_timezone', there's no indication of appropriate contexts, exclusions, or prerequisites, leaving the agent to infer usage.

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

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/pshempel/mcp-time-server-node'

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