findtime.io MCP Server

Rank a recurring meeting time

rank_recurring_slot

Read-onlyIdempotent

Scores a weekly wall-clock meeting time across locations, including a daylight-saving week when one occurs in the next 26 weeks. weekday is a day name, time is a clock value such as 9am, and home is the IANA zone of that clock. Results include formatted shareText, a less disruptive alternative, a plannerUrl, and context for skipped or repeated local times.

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": {
      "weekday": "<weekday>",
      "time": "<time>",
      "home": "<home>"
    },
    "name": "rank_recurring_slot"
  }
}

Input Schema

Name	Required	Description
`now`	No	Optional ISO instant used as "today" when choosing the next weekday. Defaults to the current time.
`home`	Yes	IANA timezone of the recurring clock, such as America/Los_Angeles.
`time`	Yes	Clock time such as 9am or 09:00 in the home timezone.
`teamId`	No	Exact homepage Saved group name. A signed-in hosted agent loads that group when locations are omitted. Marketing and marketing are two groups. Without an account, returns teams_not_persisted.
`weekday`	Yes	Day name such as Mon or Monday. 1 is Monday and 7 is Sunday.
`workEnd`	No	Last in-hours local hour, inclusive. Default 18.
`locations`	No
`workStart`	No	First in-hours local hour. Default 9.
`_endUserId`	No	Optional opaque per-call end-user attribution token populated by the MCP host, not the LLM. Accepts a non-PII hash or token, excluding raw email addresses, names, or platform user IDs.
`occurrences`	No	How many weeks to score before adding a DST week. Default 4. Max 8.
`countryCodes`	No
`durationMinutes`	No	Optional. Only 30, 45, or 60 are written onto the planner link.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A3.8/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 the bar is lower; the description adds genuine behavioral context by stating that a DST week is included when it falls within 26 weeks and that results carry shareText, an alternative, a plannerUrl, and skip/repeat context. It does not mention auth or rate limits, but the DST-inclusion behavior is the key non-obvious trait and is disclosed.

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?

Two sentences: the first front-loads the purpose and DST scope, the second documents input formats and outputs. Dense but every clause carries information; only mild cost is that the parameter-format guidance and the return-value list are crammed into the second half.

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 12-parameter tool with 83% schema coverage, the description covers purpose, DST behavior, the three required input formats, and the shape of the returned results (shareText, alternative, plannerUrl, skip/repeat context), which compensates for the absent output schema. Omitted optional params (now, teamId, workStart/workEnd, occurrences, durationMinutes) rely on the schema, leaving a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 83%, so the baseline is 3; the description goes beyond it by pinning down the three required params' formats (weekday as a day name, time as a clock value like 9am, home as the IANA zone of that clock), which is exactly what an agent needs to fill them correctly. Optional params are left to the schema, which is acceptable at this coverage level.

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 opens with a specific verb (Scores) and a precise resource (a weekly wall-clock meeting time across locations), and calls out the DST-week handling. It implicitly distinguishes itself from one-off siblings like find_meeting_time via 'weekly'/'recurring', but never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'recurring weekly meeting time', which tells an agent the domain, but there is no explicit when-to-use versus find_meeting_time, check_proposed_time, or get_overlap_hours, and no stated preconditions. There is enough context to infer the scenario but no routing guidance.

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

All findtime.io MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.