Loading ToolBench
MCP Server for accessing Sessionize event data including speakers, sessions, and conference schedules
Six tools with consistent naming (verb_noun pattern: sessionize_get_*, sessionize_find_*, sessionize_get_schedule). All have descriptions (avg 180 chars, within 10-1024 baseline). Input schemas present with types and descriptions. Pagination support (limit/offset) on list/search tools. Key gaps: output schemas not documented in source; no error handling guidance; descriptions lack 'when to use' context and dependency hints; no enum constraints on eventId despite optional/default pattern.
Search confirmed, non-service sessions by title or description. Returns matching sessions with full details. Results are paginated; use limit/offset for broad queries. Use this when the user asks to find sessions about a topic like 'find sessions about Kubernetes' or 'sessions on AI'.
Search for a speaker by name in a Sessionize event. Returns matching speakers with full details including bio and social links. Use this when the user asks about a specific speaker like 'find speaker John Doe' or 'tell me about speaker X'.
Get the full conference schedule organized by day and time slot. Returns all sessions with their times, rooms, and speakers. Use this when the user asks 'what is the schedule?' or 'show me the conference timetable'.
List the confirmed, non-service sessions for a Sessionize event (breaks, registration and other service slots are excluded). Returns session titles, descriptions, speakers, and schedule information. Results are paginated; use limit/offset for large events. Use this when the user asks 'what sessions are available?' or 'show me all talks'.
Get all sessions for a specific speaker. Returns the list of sessions the speaker is presenting. Use this when the user asks 'what sessions does X have?' or 'what is speaker Y presenting?'.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'speaker names, bios, taglines, social links') but no structured schema is visible in source. LLMs cannot plan downstream tool calls or extract fields without knowing response structure.
No error handling guidance. Descriptions do not explain what happens on failure (e.g., invalid eventId, API timeout, no results). LLMs have no recovery path.
eventId parameter lacks dependency documentation. Descriptions state 'Optional if SESSIONIZE_EVENT_ID is set' but do not explain the fallback behavior or what happens if neither is provided. Undocumented dependencies cause silent misuse.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | <=2025-11-25 | v2 |
List all speakers for a Sessionize event. Returns speaker names, bios, taglines, and social links. If eventId is not provided, uses the configured default event. Results are paginated; use limit/offset for large events. Use this when the user asks 'who are the speakers?' or 'show me all speakers'.
Descriptions lack 'when to use' context. While descriptions include example user queries, they do not explain when to prefer one tool over another (e.g., when to use sessionize_find_session vs sessionize_get_sessions). This forces LLMs to guess.
No result limits enforced in descriptions. Pagination parameters (limit, offset) are documented, but descriptions do not state the maximum result cap or warn about context window impact of large result sets.