Skip to main content
Glama

List WWDC sessions for a year

wwdc_list_sessions
Read-onlyIdempotent

Browse WWDC sessions by year and filter by topic, transcript, or sample-code availability to quickly find session numbers, titles, durations, and availability flags.

Instructions

Browse all sessions for a given WWDC year with optional topic, transcript, and sample-code filters. Returns session number, title, duration, and flags for transcript/sample-code availability.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearYesWWDC year, e.g. 2024.
limitNo
topicNoTopic substring filter, e.g. 'SwiftUI', 'Swift Concurrency'.
formatNoResponse formatmarkdown
offsetNo
sort_byNoSort column.session_number
sort_dirNoSort direction.asc
has_transcriptNoOnly return sessions with an indexed transcript.
has_sample_codeNoOnly return sessions with sample code URLs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorld=false, and non-destructive, so the safety profile is covered. The description adds a partial view of the return shape (session number, title, duration, transcript/sample-code flags) but says nothing about pagination or result-set size behavior despite limit/offset params.

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 tightly-packed sentences with the primary action and scope front-loaded and no filler. Every clause carries information.

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 9-param list tool with no output schema, the description usefully sketches the returned fields and the main filter axes. It leaves pagination and sort behavior to the schema, which is acceptable, but a note on result limits would have made it fully self-sufficient.

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 78%, so the schema does most of the work. The description echoes the topic, transcript, and sample-code filters but adds no syntax or semantic detail beyond what the schema already documents, and ignores limit/offset/sort entirely.

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 (browse/list) and resource (WWDC sessions) with clear scope (for a given WWDC year), which distinguishes it from wwdc_search and wwdc_get_session. It doesn't explicitly name the sibling it competes with, so it stops short of a 5.

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 — enumerate sessions by year with optional filters — but there is no explicit when-to-use vs when-not-to-use guidance and no named alternative for query-based lookup (e.g. wwdc_search). Adequate but with a clear gap.

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