Sonar Connections

Get the agenda or lineup

events_whats_on

Read-only

Agenda sessions and performances with their times. when accepts "all" (default), "today", "now" (the next few hours) or a YYYY-MM-DD date. Each row carries a speakers array in the order the session lists them, with each speaker's name, role (what the organizer published for that PERSON - "Moderator", "Judge" - it is a speaker-level note, so do not read it as "the moderator of this one session"), title (their job title line, which is a different fact from role and both may be present), company, bio, expertiseTags, socialLinks, a portrait photo URL, and a link to the organizer's own speaker profile page. Any of these except the name may be null or absent, which means the organizer did not publish it: say nothing rather than filling the gap. speakerNames is still there for the plain lineup.

Input Schema

Name	Required	Description	Default
`when`	No	"all" \| "today" \| "now" \| YYYY-MM-DD
`eventIdOrSlug`	Yes	Event id, public slug, or the event name as events_list spells it; short forms such as "the stroll" work.

Output Schema

Name	Required	Description	Default
`when`	No
`count`	No
`error`	No
`found`	No
`eventId`	No
`message`	No
`sessions`	No
`timezone`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / eventIdOrSlug / description

Previous value: -"Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it (\"Summer Stroll & Savor\"). Common short forms work too (\"the stroll\", \"tie summit\")."New value: +"Event id, public slug, or the event name as events_list spells it; short forms such as \"the stroll\" work."

Changed1 schema field changedOct 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "anyOf": [
+    {
+      "required": [
+        "found",
+        "eventId",
+        "when",
+        "count",
+        "sessions"
+      ]
+    },
+    {
+      "properties": {
+        "ok": {
+          "const": false
+        }
+      },
+      "required": [
+        "ok"
+      ]
+    },
+    {
+      "properties": {
+        "found": {
+          "const": false
+        }
+      },
+      "required": [
+        "found"
+      ]
+    },
+    {
+      "required": [
+        "error"
+      ]
+    }
+  ],
+  "properties": {
+    "count": {
+      "type": "integer"
+    },
+    "error": {
+      "type": "string"
+    },
+    "eventId": {
+      "type": "string"
+    },
+    "found": {
+      "type": "boolean"
+    },
+    "message": {
+      "type": "string"
+    },
+    "sessions": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "timezone": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "when": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 21, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real behavioral context beyond them: it warns that almost every speaker field may be null or absent because the organizer didn't publish it, and instructs the agent to 'say nothing rather than filling the gap.' That is a meaningful anti-hallucination guardrail. It stops short of covering pagination or result size.

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?

Purpose is front-loaded in the first sentence, which is good, but the body is a dense run-on catalog of return fields with a long parenthetical about role-vs-title that largely duplicates the output schema. Several clauses could be trimmed without losing agent-relevant guidance.

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?

Since an output schema exists, the description needn't enumerate return fields, yet it does add the crucial 'may be null, don't invent it' semantic that a schema alone cannot convey. The main gap is the absence of explicit routing guidance against sibling tools like events_speakers.

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 coverage is 100% and the enum-like `when` values plus the flexible `eventIdOrSlug` (id, slug, name, short forms) are already documented in the schema. The description restates the `when` options but adds no new syntax or edge-case meaning for either parameter, so it scores at the high-coverage baseline.

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 opening sentence names the specific resource (agenda sessions and performances) and includes times, so an agent knows this is the schedule-retrieval tool. It implicitly contrasts with the plain lineup (speakerNames / events_speakers) but never names that sibling directly, so differentiation is suggestive rather than explicit.

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: the `when` values show how to scope the query, and the closing mention of `speakerNames` gestures at the plain-lineup alternative. There is no explicit statement of when to choose this over events_speakers or events_get, nor any prerequisite or exclusion.

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

All Sonar Connections 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?