Every San Francisco movie showtime — chains, indies, repertory — verified twice daily. Free & open.
Average 4.3/5 across 9 of 9 tools scored.
Most tools have clearly distinct query shapes: film lookup, theater card, discount list, coming-soon radar, and recommendation planner are easy to separate. Some overlap exists because several tools expose showtimes from different angles (e.g. scenef_whats_playing vs. scenef_now, and scenef_film_details vs. scenef_search_showtimes), but the descriptions provide enough grounding that an agent can usually select correctly.
Every tool is prefixed with scenef_ and uses snake_case, which gives a consistent visual identity. Nevertheless, the pattern after the prefix is mixed: some names are nouns (scenef_discounts, scenef_accuracy), some are time references (scenef_now, scenef_coming_soon), and some are verb-first (scenef_search_showtimes, scenef_plan_movie_night). It is readable but not a single predictable verb_noun convention.
Nine tools is right in the ideal range and each tool earns its place in the SF showtimes domain. The set covers discovery, detail lookups, discounts, recommendations, and data-accuracy verification without feeling padded or bloated.
The domain is covered broadly: film discovery, film details, theater details, per-film showtimes, coming soon, discounts, nightly overview, personalized planning, and accuracy metrics. The main gap is that there is no simple cross-film showtimes-for-a-specific-date listing, but agents can usually work around this with scenef_whats_playing and scenef_search_showtimes.
scenef_accuracyThe accuracy recordAAccuracy is computed, not claimed: every showtime carries a confidence level, a source tier, and a last-verified time, and the running record of our own verification checks — failures included — is public at https://scenef.com/api/accuracy. This tool returns that record: the site-wide confidence mix, the counts of verification checks confirmed / missing / unreachable over the record's window (window_days in the payload — 30 days at present) with the pass rate and the exact denominator it was computed from, the same per venue with source tier and last-verified time, and the definitions of every level. Checks that could not run — a bot wall, a client-rendered page — are graded unreachable and excluded from the pass rate rather than counted as passes. Quote these numbers directly; they are recomputed on every call.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| docs | Yes | |
| site | Yes | |
| method | Yes | |
| venues | Yes | |
| data_as_of | Yes | |
| attribution | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds genuinely useful behavioral detail beyond them: numbers are recomputed on every call, checks that cannot run are graded 'unreachable' and excluded from the pass rate rather than counted as passes, and the data window is 30 days. This materially affects how an agent should interpret the numbers. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (several sentences), but it is dense with non-redundant information — every clause adds a distinct fact (public URL, window length, unreachable grading, recomputation). The core purpose is front-loaded in the first clause. It could be tightened into shorter bullets for scannability, but there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one optional parameter and an output schema present, the description is thorough: it explains what is returned (site-wide confidence mix, verification counts, per-venue pass rates, level definitions), the window semantics, the exclusion logic for unreachable checks, and invokes the public data URL. Little an agent needs to interpret the result correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the single response_format parameter has a description explaining 'concise' vs 'detailed' and what each adds. The tool description adds minimally beyond that; it mentions 'ids, per-showtime ticket urls' but these are already in the schema description. Baseline 3 applies since the schema already carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first clause immediately establishes the tool's purpose: 'returns that record' — the accuracy/verification record of showtimes. It clearly differentiates from siblings by being the only tool concerned with accuracy metrics (confidence, source tier, pass rates) rather than showtimes, films, or theaters. The verb 'returns' plus the specific resource (the accuracy record) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description carries a direct instruction, 'Quote these numbers directly; they are recomputed on every call,' which tells the agent when and how to use the output. It implies usage context by being the only tool serving verification/accuracy data, distinguishing it from the showtime and film sibling tools, though it never names an alternative explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenef_coming_soonComing soon (on-sale radar)AFilms whose first SF screening is more than 48 hours out, sorted by first night — the on-sale radar for runs worth booking early. Configurable horizon. In "detailed" mode every showtime also carries its confidence level, source tier, reporting sources, and verified_at timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| horizon_days | No | How far ahead to look (default 21 days). | |
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| films | Yes | |
| data_as_of | Yes | |
| film_count | Yes | |
| attribution | Yes | |
| accuracy_url | Yes | |
| horizon_days | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the burden of behavioral disclosure. It reveals sorting order, configurable horizon, and mode-specific output details such as confidence level, source tier, reporting sources, and verified_at timestamp. It could go further by describing the concise mode's exact contents, but overall the behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the first defines the listing and sort, the second points out the horizon parameter, and the third explains the difference between output modes. It is compact, front-loaded, and lacks fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with two parameters, the description is nearly complete. It covers what is returned, sorting, horizon configurability, and the detailed output. It does not explicitly describe the concise output shape or mention pagination, but these are not critical for choosing and cold-calling this tool successfully given the supporting schemas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters and their defaults. The description adds value by detailing what 'detailed' response_format produces—confidence level, source tier, reporting sources, and verified_at timestamp—which goes beyond the schema's vague 'other metadata.' This enrichment justifies a score slightly above the baseline for fully annotated parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description defines exactly what the tool returns: films whose first SF screening is more than 48 hours out, sorted by first night. This directly differentiates it from siblings like scenef_now or scenef_whats_playing, which target current showings, and from search_showtimes, which searches across showtimes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear trigger condition: use this when you need to see on-sale films opening more than 48 hours in the future, especially for advance booking. It implies the contrast with currently playing films through the 48-hour cutoff, though it does not name alternative tools or explicitly say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenef_discountsDiscount gridAEvery structured discount across all SF theaters — venue, label, detail, and day-bound days — with the ones that apply today flagged.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| venues | Yes | |
| today_dow | Yes | |
| data_as_of | Yes | |
| today_name | Yes | |
| attribution | Yes | |
| accuracy_url | Yes | |
| applies_today_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as safe read-only and non-destructive. The description adds useful behavioral context: it returns all structured discounts, not just today's, and marks the ones currently applicable. This clarifies a potential edge case where an agent might assume the tool only returns today's discounts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
In one concise sentence, the description establishes the scope (all SF theaters), the content (venue, label, detail, day-bound days), and the key behavior (today's discounts flagged). There is no filler or repeated schema content, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero required parameters, full param schema coverage, and an output schema. The description provides enough contextual grounding for what data is included and how today's deals are marked, so an agent can correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, response_format, is fully described in the schema with concise and detailed modes. The tool-level description does not need to repeat parameter details and adds nothing beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the scope: every structured discount across all SF theaters, including the fields returned such as venue, label, detail, and day-bound days. It also notes today-applicable discounts are flagged. However, it has no explicit verb like 'lists' or 'retrieves', and instead uses a fragment, which slightly weakens the purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across all SF theaters' gives clear context that this tool is the comprehensive discount lookup covering every venue. It does not explicitly name alternative tools, but the discount-specific scope makes when to use it apparent. There are no exclusions or alternative paths described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenef_film_detailsFilm detailsAThe full card for one film: title, year, runtime, genres, directors, cast, overview, rating, trailer and poster urls when present, every upcoming showtime with venue/time/ticket link, and a last-night flag when the run is ending. In "detailed" mode every showtime also carries its confidence level, source tier, reporting sources, and verified_at timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| film | Yes | Film title or SceneF slug. | |
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| film | No | |
| query | Yes | |
| matched | Yes | |
| showtimes | No | |
| candidates | No | |
| data_as_of | Yes | |
| attribution | Yes | |
| final_night | No | |
| accuracy_url | Yes | |
| is_last_night | No | |
| showtime_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations shown, so the description must carry the burden of behavioral disclosure. It does include useful behavioral detail such as 'when present', a 'last-night flag', and mode-dependent showtime fields, but it does not disclose other behavioral traits like read-only nature, possible absences, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense rather than verbose; it bundles a comprehensive field list into two sentences without repetition. The conditional qualifiers like 'when present' and 'when the run is ending' are meaningful and not wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema is provided, the description does a strong job of telling the agent what the response will contain for both concise and detailed modes. It is complete enough for a single-card retrieval operation, though it could have added explicit notes about defaults or fallback behavior if showtimes are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters: 'film' accepts a title or slug, and 'response_format' controls concise vs detailed mode. The description adds extra semantic value by explaining what 'detailed' mode actually includes, such as confidence level, source tier, reporting sources, and verified_at timestamp.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns 'the full card for one film' and then enumerates the exact set of fields and content it contains. This clearly identifies the tool's purpose and distinguishes it from sibling tools that handle search, showtime lookup, or venue info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need the complete card for a single film, including showtimes, credits, rating, and poster. It does not explicitly state when not to use this tool versus its siblings, but the single-film scope and full-card framing make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenef_nowRight nowAThe cheap is-anything-on call: how many screenings tonight, the next 5 curtains city-wide with venue/time/film, and dataset freshness per source. In "detailed" mode every showtime also carries its confidence level, source tier, reporting sources, and verified_at timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| sources | Yes | |
| night_of | Yes | |
| data_as_of | Yes | |
| is_tonight | Yes | |
| attribution | Yes | |
| accuracy_url | Yes | |
| next_curtains | Yes | |
| still_to_come | Yes | |
| screenings_tonight | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail about output: it returns counts, freshness, and in detailed mode extra per-showtime metadata. It also implies lightweightness ('cheap'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. The first packs the core purpose and outputs, the second clarifies the mode-specific addition. Zero fluff, front-loaded with the 'cheap is-anything-on' hook and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter, read-only tool with an output schema present, the description fully covers what an agent needs to decide and call it correctly. It explains the count, the five shows with details, freshness, and the detailed mode extras. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is well-documented. The description adds meaning beyond the schema by explicitly listing what the 'detailed' mode includes (confidence level, source tier, reporting sources, verified_at timestamp), which enriches the semantic understanding beyond the generic 'extra metadata' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('call') and resource ('is-anything-on' for tonight), and lists concrete outputs: count, next 5 curtains city-wide with venue/time/film, and dataset freshness. It clearly distinguishes itself from siblings like scenef_coming_soon (future) and scenef_whats_playing (what's playing) by focusing on the immediate 'tonight' and the lightweight 'cheap' nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by calling it 'the cheap is-anything-on call' and scoping to 'tonight' and 'next 5 curtains city-wide'. It implies when to use it (quick check for immediate availability) but does not explicitly state when-not to use it or name alternatives, which would push to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenef_plan_movie_nightPlan a movie nightAThe concierge: give it a window and a taste profile and it returns 2-4 complete plans — film + specific showtime + theater + why it fits — each with ticket and calendar links, plus one wildcard pick outside the stated genres. Rankings are pure preference-fit; never pay-ranked. In "detailed" mode every showtime also carries its confidence level, source tier, reporting sources, and verified_at timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| when | No | When to look: "tonight" (default), "tomorrow", "weekend" (Fri/Sat/Sun of the current week), or a YYYY-MM-DD date. | |
| party_size | No | How many people are going. | |
| preferences | No | Bring-your-own taste profile. Everything here tilts the ranking and degrades gracefully EXCEPT time_after/time_before, which are hard bounds. | |
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| plans | Yes | |
| nights | Yes | |
| window | Yes | |
| wildcard | Yes | |
| data_as_of | Yes | |
| party_size | Yes | |
| plan_count | Yes | |
| attribution | Yes | |
| accuracy_url | Yes | |
| discounts_relaxed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, but the description adds significant behavioral detail: rankings are pure preference-fit and never pay-ranked, and detailed mode includes confidence levels, source tier, reporting sources, and timestamps. It also mentions a wildcard pick and that time bounds are hard (though that is in the schema). This goes well beyond annotation defaults, so it fully carries the burden of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff. The first sentence front-loads the purpose and output, the second explains the ranking philosophy and detailed mode. Every sentence earns its place; no redundant clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with nested preferences and an output schema, the description covers the key aspects: what plans look like, ticket/calendar links, wildcard behavior, ranking policy, and detailed-mode metadata. The hard-bound behavior is in the schema descriptions, so it is not missing. The description is fully sufficient for an agent to understand what it does and when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with thorough descriptions for all parameters, including nested preferences and the hard-bound semantics of time_after/time_before. The description summaries this as 'a window and a taste profile', which adds minimal extra meaning. Per the baseline rule, when schema fully covers parameters, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it takes a window and a taste profile and returns 2-4 complete movie plans with film, showtime, theater, and reasoning. The output format (plans, links, wildcard) is specific, and the 'concierge' framing distinguishes it from sibling tools like search_showtimes or now. It is a clear, resource-specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what inputs to provide ('give it a window and a taste profile') and what to expect (plans with links). It does not explicitly mention when to avoid this tool in favor of a sibling, but it implies usage for the specific task of planning a movie night. This is a clear usage context without explicit exclusions, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenef_search_showtimesSearch showtimes for a filmAShowtimes scoped by FILM or by THEATER — pass at least one. With film: where that film is playing (title or slug; fuzzy-matched, ambiguous queries return candidates). With venues and no film: everything on at those theaters, each showtime naming its film. Grouped by theater with local times, tags (35mm/qa/sold-out), the night each show belongs to, and a ticket link per showtime. Optional date and time-window filters apply to both. For the whole board with no film or theater in mind, call scenef_whats_playing instead. In "detailed" mode every showtime also carries its confidence level, source tier, reporting sources, and verified_at timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Restrict to one night, YYYY-MM-DD. | |
| film | No | Film title, or a SceneF slug taken from films[].slug / scenef_whats_playing. A title that is not on the board answers with a miss and points at scenef_whats_playing, so guessing is safe but browsing is faster. Optional when `venues` is given — omit it to ask what is on at a theater. | |
| venues | No | Restrict to these theaters (ids or names), e.g. ["roxie", "Balboa"]. Required when `film` is omitted. | |
| time_after | No | Only shows at or after this local time, "HH:MM" 24h. | |
| time_before | No | Only shows at or before this local time, "HH:MM" 24h. | |
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| film | No | |
| query | Yes | |
| venues | Yes | |
| matched | Yes | |
| refusal | No | |
| candidates | No | |
| data_as_of | Yes | |
| attribution | Yes | |
| filtered_by | No | |
| accuracy_url | Yes | |
| coverage_note | Yes | |
| showtime_count | Yes | |
| unknown_venues | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a safe read-only operation; the description adds rich behavioral context: fuzzy matching, ambiguous-query candidate responses, a miss behavior that points to the sibling, grouping by theater, tags, local times, ticket links, and detailed-mode metadata. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence adds distinct operational value: scoping modes, filters, output grouping, alternative routing, and detailed-mode extras. It is front-loaded with the core scoping constraint and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 optional parameters, two scoping modes, fuzzy matching, and a detailed output mode, the description covers all the essential call decisions. Since an output schema exists, return-value details do not need to be repeated, and none of the operationally critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond field names: it explains the film-or-venues dependency, how slugs relate to films[]/scenef_whats_playing, what happens with unmatched titles, and what 'detailed' response_format adds. This significantly helps an agent choose and fill parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what the tool does: searches showtimes scoped by film or theater. It distinguishes itself from the sibling scenef_whats_playing by clarifying that this tool is for film-or-theater scoped queries, while the sibling is for the whole board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('with film', 'with venues and no film') and when to use the alternative ('call scenef_whats_playing instead' for the whole board). It also gives the important constraint 'pass at least one' and describes behavior for ambiguous or missing films.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenef_theater_infoTheater infoAOne SF theater's card: address, neighborhood, website, ticketing note, structured discounts (label/detail/day), amenities, its next 5 showtimes with ticket links, and its calendar feed url. In "detailed" mode every showtime also carries its confidence level, source tier, reporting sources, and verified_at timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| theater | Yes | Theater id or name, e.g. "roxie" or "Balboa Theater". | |
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| venue | No | |
| matched | Yes | |
| upcoming | No | |
| candidates | No | |
| data_as_of | Yes | |
| attribution | Yes | |
| accuracy_url | Yes | |
| upcoming_count | No | |
| covered_venue_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly and non-destructive behavior, so the bar is lower. The description adds substantial behavioral detail: the exact card contents, the 'next 5 showtimes with ticket links', and exactly what 'detailed' mode adds (confidence level, source tier, reporting sources, verified_at timestamp). It does not disclose possible failure modes or what happens if a theater is not found, but it offers useful behavioral specificity beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, front-loaded summary that uses no filler words. It leads with the core object ('one SF theater's card'), enumerates the natural card elements, and adds a single sentence for the mode variation. Every sentence adds distinctive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only informational tool with only two parameters, a fully described schema, and an output schema present, the description gives enough context to make a correct call: it tells what data will appear, what 'detailed' mode changes, and what the output includes. No required fields or behaviors appear missing from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage, so the basis is strong. The description adds semantics by elaborating specifically on the 'detailed' response_format: each showtime carries confidence level, source tier, reporting sources, and verified_at timestamp. This gives an agent more conceptual meaning about the response_format enum than the schema's generic 'extra metadata'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns one SF theater's info card and enumerates its contents (address, neighborhood, website, ticketing note, discounts, amenities, showtimes, calendar feed). The title itself is vague, but the description makes the resource and scope clear. It does not explicitly distinguish itself from siblings such as scenef_search_showtimes, which also involve showtimes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for getting a single theater's aggregated details, but it never explicitly says when to choose this tool over scenef_search_showtimes, scenef_whatds_playing, or scenef_discounts. It also mentions concise vs. detailed mode, giving partial operational guidance. No clear 'use this instead of X' or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scenef_whats_playingWhat's playing in SFARanked list of films playing San Francisco theaters in a given window (tonight, tomorrow, the weekend, or a date), with optional genre and format filters. When the window covers tonight, opens with Notable tonight — scarcity facts with evidence (measured seat counts, final nights, lone prints, posted discounts, live elements); lead with those when asked what to see. Each entry carries year, runtime, genres, a one-line hook, venue count, the next showtime, and the film's SceneF url. In "detailed" mode every showtime also carries its confidence level, source tier, reporting sources, and verified_at timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| when | No | When to look: "tonight" (default), "tomorrow", "weekend" (Fri/Sat/Sun of the current week), or a YYYY-MM-DD date. | |
| genres | No | Genre filters, e.g. ["horror", "comedy"]. | |
| formats | No | Format/tag filters, e.g. ["35mm", "70mm", "qa", "live-score"]. | |
| max_results | No | Max films to return (default 12, cap 25). | |
| response_format | No | Output size: "concise" (default) for tight text lines, "detailed" to add ids, per-showtime ticket urls, and extra metadata. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| films | Yes | |
| nights | Yes | |
| window | Yes | |
| notable | Yes | |
| data_as_of | Yes | |
| film_count | Yes | |
| attribution | Yes | |
| accuracy_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as read-safe, and the description adds substantial behavioral context beyond that: results are ranked, the top section uses scarcity evidence like measured seat counts and final nights, and detailed mode exposes confidence levels, source tier, and verified_at. This gives the agent a realistic picture of answer behavior before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: the core ranked-list purpose is in the first clause, and each later clause adds a new configurable point (windows, filters, Notable tonight, entry fields, detailed mode). It is long but not bloated, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given all parameters are optional, all are schema-description covered, and an output schema exists, the description completes the picture well: it covers window semantics, ranking behavior, both modes, distinct scarcity evidence, and exact entry fields. Nothing essential for the agent to call it correctly appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a useful description, enum, or default. The description recaps genre/format filters and explains 'detailed' mode a little, but does not meaningfully expand on parameter syntax beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete output: 'Ranked list of films playing San Francisco theaters in a given window' and enumerates filters, ranking, and entry fields. It is clearly a discovery/list tool, but it does not explicitly differentiate itself from siblings such as scenef_search_showtimes or scenef_now, so it misses the full sibling-contrast criterion for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful context about when the 'tonigth/tonight' window triggers 'Notable tonight' and advises to lead with those when asked what to see. However, it never says when not to use this tool or mentions any sibling alternative (search, coming soon, theater info), so the guidance is reasonably impliesed rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Original film criticism: multi-framework readings, TakeScore ratings, kindred films.
Cartelera de España: películas, cines, sesiones, recomendaciones y enlaces de compra.
Live LA events, ticket price comparison, bars & nightlife with real-time happy hours
