Skip to main content
Glama

Cinve

Listar películas

list_movies
Read-onlyIdempotent

Busca películas por nombre. Cinepic requiere cinema_id (123300 Candelaria o 123301 VVIP Lido) y filtra funciones del día; Cines Unidos requiere city y permite cinema_id/date. Cinex devuelve catálogo general sin fecha/sede: solo provider, query y paginación. Supercines devuelve su cartelera vigente (con preventa), general o de una sede con cinema_id, sin fecha. Gran Cine devuelve los títulos con funciones en la fecha, con cinema_id o city opcionales. Los IDs pertenecen al proveedor y, en Cinepic, a la sede.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "provider": "<provider>"
    },
    "name": "list_movies"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNoNombre de ciudad tal como lo devuelve list_cities del mismo proveedor (p. ej. Caracas); no distingue tildes ni mayúsculas en Cines Unidos.
dateNoYYYY-MM-DD; por defecto hoy en America/Caracas para películas y funciones de Cinepic/Cines Unidos y funciones de Cinex, Supercines y Gran Cine.
limitNo
queryNoFiltra por nombre, sin distinguir tildes/mayúsculas.
offsetNo
refreshNotrue: consulta al proveedor sin usar caché local; solicita revalidación HTTP. No garantiza que el proveedor haya actualizado su contenido.
movie_idNoID de película devuelto por list_movies del mismo proveedor; opcional en Cinex cuando se consulta una sede completa.
providerYesProveedor de cine; obtén capacidades y limitaciones con list_providers.
cinema_idNoID de sede devuelto por list_cinemas del mismo proveedor. No mezcles IDs entre proveedores. Si la sede incluye code_status, usa cinema_id solo cuando sea verified; los IDs directory-* no permiten consultas.

Output Schema

NameRequiredDescriptionDefault
itemsYes
totalYes
statusYes
partialYes
sourcesYes
providerYes
timezoneYes
warningsYes
queried_atYes
next_offsetYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description clears it by disclosing provider-specific semantics: Cinex returns a general catalog, Supercines returns the current billboard including presale, Gran Cine returns only titles with showtimes on the date. It also warns that IDs are provider-scoped. It does not address pagination applicability across providers or caching implications of the provider-specific paths.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause and every subsequent sentence carries provider-specific information with little filler. It is a single dense paragraph with no visual separation between providers, which makes scanning harder than a short list would be, but no sentence is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter, five-provider tool with an output schema present, the description covers the critical unknowns: which parameters each provider honors and what shape of result each returns. Remaining gaps (limit/offset have no schema descriptions and pagination is mentioned only for Cinex) are minor relative to what is already explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 78%, just below the high-coverage baseline, and the description compensates by mapping which parameters are meaningful per provider (cinema_id vs city vs date) and stating that Cinex accepts only provider, query and pagination. That is meaning the schema alone does not convey, since the schema marks only provider as required and leaves the rest silently optional.

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?

Opens with a specific verb+resource ("Busca películas por nombre") and then differentiates what each of the five providers returns, which is the real distinguishing axis for this tool. It never explicitly contrasts itself with get_showtimes, even though Cinepic's day-filtered behavior overlaps that sibling's territory, so an agent must infer the boundary.

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?

Per-provider requirements (Cinepic requires cinema_id, Cines Unidos requires city, Cinex/Supercines take no date) function as de-facto usage guidance and are genuinely useful. However, there is no explicit when-to-use/when-not-to-use framing and no named alternative for the showtime-vs-catalog distinction, so the agent must derive routing rules itself.

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.