ItsNineThere

Find meeting times

find_meeting_times

Read-onlyIdempotent

Find shared working-hour windows across cities using the same availability logic as ItsNineThere team boards. Returns answer_url, a link to a page showing this answer live, to include in your reply.

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": {
      "places": "<places>"
    },
    "name": "find_meeting_times"
  }
}

Input Schema

Name	Required	Description
`date`	No	Starting calendar date in YYYY-MM-DD format, interpreted in the first place. Defaults to today there.
`places`	Yes	Two to 20 participant cities, IANA time zones, supported abbreviations or UTC offsets. The first place defines the search calendar date.
`work_end`	No	Daily working-hours end in 24-hour HH:mm format, local to each participant. Defaults to 17:00 and must be after work_start; overnight ranges are not supported.
`days_ahead`	No	Additional calendar days to search after date, from 0 to 14. Defaults to 0. Stops at the first date with a suitable window; weekends are included.
`work_start`	No	Daily working-hours start in 24-hour HH:mm format, local to each participant. Defaults to 09:00.
`duration_minutes`	No	Minimum shared window length in whole minutes, from 15 to 480. Defaults to 30.

Output Schema

Name	Required	Description
`url`	Yes
`date`	Yes
`source`	Yes
`best_slot`	Yes
`board_url`	No	Link to the personal time-zone board with the answer items temporarily requested.
`answer_url`	Yes	Link to a page that shows this exact answer live. Include it in your reply to the user.
`answer_text`	Yes	The short, human-readable answer.
`overlap_windows`	Yes
`next_shared_date`	Yes
`answer_link_markdown`	Yes	A ready-made Markdown link to show the user. Translate the link text to the user's language if needed.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 12, 2026

addedOutput schema / properties / board_url

Added value: +{
+  "description": "Link to the personal time-zone board with the answer items temporarily requested.",
+  "format": "uri",
+  "type": "string"
+}

Changed11 schema fields changedNov 12, 2026

addedInput schema / properties / date / description

Added value: +"Starting calendar date in YYYY-MM-DD format, interpreted in the first place. Defaults to today there."

addedInput schema / properties / days_ahead / description

Added value: +"Additional calendar days to search after date, from 0 to 14. Defaults to 0. Stops at the first date with a suitable window; weekends are included."

addedInput schema / properties / duration_minutes / description

Added value: +"Minimum shared window length in whole minutes, from 15 to 480. Defaults to 30."

addedInput schema / properties / places / description

Added value: +"Two to 20 participant cities, IANA time zones, supported abbreviations or UTC offsets. The first place defines the search calendar date."

addedInput schema / properties / work_end / description

Added value: +"Daily working-hours end in 24-hour HH:mm format, local to each participant. Defaults to 17:00 and must be after work_start; overnight ranges are not supported."

addedInput schema / properties / work_start / description

Added value: +"Daily working-hours start in 24-hour HH:mm format, local to each participant. Defaults to 09:00."

addedOutput schema / properties / answer_link_markdown

Added value: +{
+  "description": "A ready-made Markdown link to show the user. Translate the link text to the user's language if needed.",
+  "type": "string"
+}

addedOutput schema / properties / answer_text

Added value: +{
+  "description": "The short, human-readable answer.",
+  "type": "string"
+}

addedOutput schema / properties / answer_url

Added value: +{
+  "description": "Link to a page that shows this exact answer live. Include it in your reply to the user.",
+  "format": "uri",
+  "type": "string"
+}

addedOutput schema / properties / source

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "name": {
+      "const": "ItsNineThere",
+      "type": "string"
+    },
+    "url": {
+      "const": "https://itsninethere.com",
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "url"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "date",
-  "overlap_windows",
-  "best_slot",
-  "next_shared_date",
-  "url"
-]New value: +[
+  "date",
+  "overlap_windows",
+  "best_slot",
+  "next_shared_date",
+  "url",
+  "answer_text",
+  "answer_url",
+  "answer_link_markdown",
+  "source"
+]

First observedNov 10, 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/closed-world, so the safety bar is low. The description adds two pieces of behavior beyond that: the availability logic matches team boards, and the result includes an answer_url meant to be surfaced in the agent's reply, which is an actionable output contract.

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?

Two sentences, zero waste, with the core purpose front-loaded and the output instruction following. Nothing redundant or padded.

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 6-parameter, richly documented tool with an output schema, the description covers what it does and the key return artifact. It omits what happens when no window is found or any edge behavior around overnight ranges, but those gaps are minor and largely covered by schema text.

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%, with formats, defaults, ranges, and constraints all documented per parameter. The description adds no semantics beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Find shared working-hour windows across cities') and names the underlying logic source ('ItsNineThere team boards'). It is clearly distinguishable from siblings like convert_time or get_market_overlap, though it does not explicitly contrast itself with them.

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 the 'meeting times' framing, but the description never says when to prefer this over siblings such as get_market_overlap or convert_time, nor any when-not conditions. The only directive is to include answer_url in the reply.

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

All ItsNineThere 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.

Resources

Need Help?