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

@findtime/mcp-server

by hkchao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

are_they_awake

Read-onlyIdempotent

Check whether people in other cities are awake, working, or asleep at a chosen time so you can decide whether to message them.

Instructions

Say whether people in other cities are in work, awake, or sleep at a moment. Use for "3pm for me — can I ping Bangalore?". myTime defaults to now. Pass myTimezone as an IANA id or myCity as a place. Paste shareText. A rough window includes a plannerUrl with better aiSlots.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "are_they_awake"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD when myTime is only a clock time.
myCityNoCaller city, used when myTimezone is omitted.
myTimeNoISO instant, or a floating local time in myTimezone. Defaults to now.
workEndNoLast in-hours local hour, inclusive. Default 18.
locationsNo
theirCityNoOne city or timezone to judge.
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.
myTimezoneNoIANA timezone for the caller, such as America/Los_Angeles.
theirCitiesNo
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

A3.6/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely behavioral facts: myTime defaults to now, and the response carries a shareText and, for a rough window, a plannerUrl with 'better aiSlots.' However, 'Paste shareText' is opaque — it never says shareText comes from the output or what it contains — so the disclosure is partial rather than clean.

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?

Purpose is front-loaded in the first sentence and the whole thing is four short sentences with no padding. The cost is that the trailing fragments ('Paste shareText.') are compressed past the point of parsing, trading clarity for brevity.

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?

For an 11-parameter tool with no output schema, the description should carry more of the return-value and mode-selection burden. It hints at outputs (shareText, plannerUrl) and at a work-hours window, but leaves the awake/sleep thresholds, the alias parameters, and the actual response shape unexplained.

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 82%, so the schema already documents nearly every parameter, including the same IANA-id guidance the description repeats. The description adds little beyond that baseline: it never explains theirCity vs theirCities vs the locations alias, nor how workStart/workEnd define the in-hours window, nor that durationMinutes is restricted to 30/45/60.

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 verb and resource are concrete: judge whether people in other cities are 'in work, awake, or sleep at a moment.' That is a distinct capability from siblings like get_current_time or get_overlap_hours. It stops short of naming any sibling explicitly, so the agent must infer the boundary itself.

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 quoted scenario ('3pm for me — can I ping Bangalore?') gives a clear, memorable trigger condition, which is exactly the agent-relevant context for this tool. There is no when-not guidance and no routing to adjacent tools such as get_overlap_hours or find_meeting_time, which would have made it a 5.

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