Skip to main content
Glama

SceneF — California, Florida and Hawaii Movie Showtimes

The accuracy record

scenef_accuracy
Read-only

Accuracy 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNoWhich regional board to read, e.g. "sf", "oahu", "sacramento". Omitted means the default board — it is never inferred from where you are. Call scenef_now for the full list; an unknown region is an error, not a fallback.
response_formatNoOutput size. "concise" (default) is tight text plus a structured summary. In whats_playing, each film has the total showtime_count, next_showtime, and a showtimes array containing only that next screening; showtimes_complete says whether the array is exhaustive. "detailed" includes all selected showtime rows with ids, ticket urls, and accuracy metadata. Use scenef_search_showtimes for all times for one film or theatre.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
docsYes
siteYes
methodYes
regionYes
venuesYes
timezoneYes
data_as_ofYes
attributionYes
region_nameYes
accuracy_urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / response_format / description
      Previous value: -"Output size. \"concise\" (default) is tight text plus a structured summary — on list-shaped tools each film carries showtime_count and next_showtime, but NOT the full showtimes array. \"detailed\" adds the per-showtime rows with ids, ticket urls, and accuracy metadata. Concise measures ~10KB where detailed measures ~69KB, so ask for detailed when you need the rows and scenef_search_showtimes when you need them for one film or theatre."New value: +"Output size. \"concise\" (default) is tight text plus a structured summary. In whats_playing, each film has the total showtime_count, next_showtime, and a showtimes array containing only that next screening; showtimes_complete says whether the array is exhaustive. \"detailed\" includes all selected showtime rows with ids, ticket urls, and accuracy metadata. Use scenef_search_showtimes for all times for one film or theatre."
    • addedOutput schema / properties / accuracy_url
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / region
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / region_name
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / timezone
      Added value: +{
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "data_as_of",
      -  "attribution",
      -  "site",
      -  "venues",
      -  "method",
      -  "docs"
      -]New value: +[
      +  "data_as_of",
      +  "attribution",
      +  "accuracy_url",
      +  "region",
      +  "region_name",
      +  "timezone",
      +  "site",
      +  "venues",
      +  "method",
      +  "docs"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / response_format / description
      Previous value: -"Output size: \"concise\" (default) for tight text lines, \"detailed\" to add ids, per-showtime ticket urls, and extra metadata."New value: +"Output size. \"concise\" (default) is tight text plus a structured summary — on list-shaped tools each film carries showtime_count and next_showtime, but NOT the full showtimes array. \"detailed\" adds the per-showtime rows with ids, ticket urls, and accuracy metadata. Concise measures ~10KB where detailed measures ~69KB, so ask for detailed when you need the rows and scenef_search_showtimes when you need them for one film or theatre."
  3. Changed1 schema field changed
    • addedInput schema / properties / region
      Added value: +{
      +  "description": "Which regional board to read, e.g. \"sf\", \"oahu\", \"sacramento\". Omitted means the default board — it is never inferred from where you are. Call scenef_now for the full list; an unknown region is an error, not a fallback.",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark readOnly and non-destructive, but the description adds substantial behavioral context: failures are public, unreachable checks are excluded from the pass rate, the window is 30 days, and results are recomputed on each call. This goes well beyond what annotations convey and gives an agent strong expectations about data provenance and edge cases.

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?

Although the description is relatively long, every sentence earns its place: it establishes provenance, states the return value, explains the unreachable-check handling, and gives usage direction. The structure is front-loaded with the core purpose and expands into necessary methodology without fluff.

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?

The main description is unusually complete for a read-only tool with annotations and an output schema, covering methodology, exclusions, denominator semantics, and recency. It falls just short of perfect because the response_format parameter's schema description appears contaminated with text about whats_playing, and the main description does not clarify the concise/detailed distinction specifically for accuracy output.

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%, so the main description is not required to re-explain region or response_format. The description contributes output-related context like window_days but does not add input-parameter semantics beyond the schema. It meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first two sentences define a clear resource — the accuracy/verification record — and a specific action: 'This tool returns that record.' It is immediately distinguishable from siblings like scenef_search_showtimes or scenef_now, which focus on showtimes or board listings rather than verification statistics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit routing guidance: 'Call scenef_now for the full list' of regions, and 'Use scenef_search_showtimes for all times for one film or theatre.' It also advises that the returned numbers should be quoted directly because they are recomputed on every call. It does not comprehensively enumerate every situation where accuracy should be preferred, but the context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources