ItsNineThere

Get market overlap

get_market_overlap

Read-onlyIdempotent

Overlap windows for stock exchanges, forex sessions or futures, including Asian Session, European Session and North American Session. 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": {
      "venues": "<venues>"
    },
    "name": "get_market_overlap"
  }
}

Input Schema

Name	Required	Description
`tz`	No	IANA viewer time zone for the calendar date and displayed session times, for example Europe/Copenhagen. Defaults to Etc/UTC.
`date`	No	Calendar date for sessions in YYYY-MM-DD format, interpreted in tz. Defaults to today in tz. Any current status fields describe now, not this date.
`venues`	Yes	Market venue IDs or aliases to compare, up to 20 entries. At least two distinct known venues are required, for example nyse and lse, or asian-session and european-session.

Output Schema

Name	Required	Description
`url`	Yes
`date`	Yes
`source`	Yes
`overlaps`	Yes
`timezone`	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.
`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"
+}

Changed8 schema fields changedNov 12, 2026

addedInput schema / properties / date / description

Added value: +"Calendar date for sessions in YYYY-MM-DD format, interpreted in tz. Defaults to today in tz. Any current status fields describe now, not this date."

addedInput schema / properties / tz / description

Added value: +"IANA viewer time zone for the calendar date and displayed session times, for example Europe/Copenhagen. Defaults to Etc/UTC."

addedInput schema / properties / venues / description

Added value: +"Market venue IDs or aliases to compare, up to 20 entries. At least two distinct known venues are required, for example nyse and lse, or asian-session and european-session."

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: -[
-  "timezone",
-  "date",
-  "overlaps",
-  "url"
-]New value: +[
+  "timezone",
+  "date",
+  "overlaps",
+  "url",
+  "answer_text",
+  "answer_url",
+  "answer_link_markdown",
+  "source"
+]

Changed1 schema field changedNov 11, 2026
- changedInput schema / properties / venues / minItems
```
Previous value: -2New value: +1
```
AddedNov 10, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare a safe, read-only, idempotent, closed-world lookup, so the remaining burden is light. The description does add useful behavior beyond them by naming the answer_url return value and instructing the agent to include it in its reply, but it omits what 'overlap' means precisely (session intersection) and what happens with unknown or fewer-than-two venues.

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 tight sentences: the resource and scope come first, and the answer_url instruction is deferred to the end where it belongs. The session enumeration earns its place by clarifying venue scope, and there is no filler.

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?

With a full input schema and an output schema present, the description need not restate parameters or return shapes, and it correctly limits itself to scope plus the answer_url convention. The only meaningful gap is the multi-venue requirement and the error behavior for invalid aliases, which the agent must discover from the schema.

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 all three parameters (venues, date, tz) are already fully documented including defaults and formats. The description adds no parameter-level detail such as syntax for venue aliases or the two-venue minimum, 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?

The description gives a specific verb and resource ('overlap windows for stock exchanges, forex sessions or futures') and enumerates the session types covered, so the agent knows exactly what is computed. It does not distinguish itself from the sibling get_market_hours, which a reasonable agent could confuse for the same question.

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 only implied: an agent can infer this is the tool for intersecting two or more venues' sessions, but there is no explicit when-to-use, when-not-to-use, or statement that get_market_hours should be preferred for a single venue's hours. The requirement for at least two distinct venues exists only in the schema, not in the description.

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?