Skip to main content
Glama
Sign In
@findtime/mcp-server

@findtime/mcp-server

by hkchao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

check_proposed_time

Read-onlyIdempotent

Judge a proposed meeting time across multiple cities, showing local times, timezone/DST issues, and up to three better slots. Use when you already have a clock time to validate for attendees.

Instructions

Judge a proposed meeting instant for each city. Use when the user already has a clock time, such as "Tuesday 9am PT with London and Tokyo — is that bad?". Pass start as an ISO instant, or as a floating local time with home set to an IANA timezone. Paste shareText. Time API computes the UTC instant, local lines, verdicts, and up to three better aiSlots. Do not invent wall-clock times. If context is set, tell the user that sentence. It says whether daylight saving skipped the local time or made it happen twice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start": "<start>"
    },
    "name": "check_proposed_time"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD when start is only a clock time.
homeNoIANA timezone for a floating start, such as America/Los_Angeles.
startYesISO instant with a UTC offset, or a floating local time such as 2026-09-29T09:00 or 9:00am.
workEndNoLast in-hours local hour, inclusive. Default 18.
locationsNo
workStartNoFirst in-hours local hour. Default 9.
_endUserIdNoOptional opaque per-call end-user attribution token populated by the MCP host, not the LLM. Use a non-PII hash or token; never send raw email, name, or platform user ID.
countryCodesNo
durationMinutesNoOptional. Only 30, 45, or 60 are written onto the planner link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.28.1

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description still adds real value by disclosing outputs (UTC instant, local lines, verdicts, up to three better aiSlots) and the DST-ambiguity context sentence about skipped or duplicated local times. The 'Paste shareText' instruction is confusing because no shareText parameter appears in the schema, slightly muddying the behavioral picture.

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

Conciseness3/5

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

The purpose and use case are front-loaded and zero-waste, but the middle sentences are choppy and one ('Paste shareText') references a field that does not exist in the schema, adding confusion rather than information. It reads as a set of appended notes rather than a structured brief.

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 9-parameter tool with no output schema, the description covers the core input contract (start/home), the outputs, and the DST edge case, which is enough for correct invocation. Minor gaps remain on the work-hours window, durationMinutes, and countryCodes hints, though the schema descriptions largely cover those.

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?

With 78% schema description coverage, the schema already documents most parameters, and the description adds useful framing for 'start' (ISO instant vs. floating local time) and 'home' (IANA zone for a floating start). It says nothing about workStart, workEnd, durationMinutes, or countryCodes, so it does not compensate much beyond the schema baseline.

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 object: 'Judge a proposed meeting instant for each city,' and the example query ('Tuesday 9am PT with London and Tokyo — is that bad?') makes the tool's job unmistakable. It also implicitly separates itself from slot-finding siblings by requiring that the user 'already has a clock time.'

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?

Gives a clear triggering condition ('use when the user already has a clock time') plus a concrete example, and a negative constraint ('Do not invent wall-clock times'). It stops short of naming the alternative sibling (e.g., find_meeting_time) for the case where no time exists yet, so routing is implied rather than explicit.

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

Deploy Server

Other Tools