Cinve

Consultar tarifas

get_ticket_prices

Read-onlyIdempotent

Consulta tarifas (Gran Cine no las publica). Cinepic requiere cinema_id, movie_id y session_id de get_showtimes. Cines Unidos requiere cinema_id, session_id y una cuenta conectada. Cinex requiere cinema_id, session_id y una cuenta conectada. Supercines requiere cinema_id, movie_id y session_id, y date si la función no es de hoy; no requiere cuenta (si el usuario conectó la suya, se leen con ella). Devuelve USD/VES cuando verificables, desglose Cinex en VES. No devuelve totales finales de compra.

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>",
      "cinema_id": "<cinema_id>",
      "session_id": "<session_id>"
    },
    "name": "get_ticket_prices"
  }
}

Input Schema

Name	Required	Description
`date`	No	Solo Supercines: fecha de la función (YYYY-MM-DD), la misma usada en get_showtimes; por defecto hoy en America/Caracas. Sus tarifas varían por día.
`limit`	No
`offset`	No
`refresh`	No	true: consulta al proveedor sin usar caché local; solicita revalidación HTTP. No garantiza que el proveedor haya actualizado su contenido.
`movie_id`	No	ID de película devuelto por list_movies del mismo proveedor; opcional en Cinex cuando se consulta una sede completa.
`provider`	Yes	Proveedor de cine; obtén capacidades y limitaciones con list_providers.
`cinema_id`	Yes	ID 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.
`session_id`	Yes	ID de función devuelto por get_showtimes del mismo proveedor.

Output Schema

Name	Required	Description	Default
`items`	Yes
`total`	Yes
`status`	Yes
`partial`	Yes
`sources`	Yes
`provider`	Yes
`timezone`	Yes
`warnings`	Yes
`queried_at`	Yes
`next_offset`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, openWorld), so the description focuses on adding context annotations cannot express: which providers need a linked account, that Gran Cine returns nothing because prices are unpublished, and that totals are never final purchase amounts. It does not cover failure/error behavior when a provider's price feed is stale or unavailable, which keeps it short of a 5.

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?

The scope exclusion is front-loaded and each sentence carries distinct information with no filler. The repeated "X requiere ..." pattern is dense and functional, though a tighter list format would scan faster than four near-identical sentences.

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?

An output schema exists, so return structure need not be spelled out, and the description still adds the non-obvious part (USD/VES only when verifiable, Cinex breakdown in VES, no final totals). Combined with the provider prerequisite matrix and the date rule, an agent has everything needed to call this correctly.

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

Parameters5/5

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

With 75% schema coverage the schema already explains individual parameters, yet the description adds conditional, cross-parameter meaning the schema cannot encode: cinepic needs cinema_id+movie_id+session_id, Cines Unidos and Cinex need cinema_id+session_id plus an account, and Supercines adds date only for non-today shows. That per-provider requirement matrix is exactly the kind of value the schema cannot carry.

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?

"Consulta tarifas" gives a specific verb and resource, and the parenthetical "(Gran Cine no las publica)" immediately scopes what the tool can and cannot retrieve. The provider-by-provider requirements make it unmistakable against siblings such as get_showtimes or get_concessions.

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?

It states per-provider prerequisites (connected account for Cines Unidos and Cinex, date for Supercines when the show is not today) and effectively excludes Gran Cine. What is missing is explicit routing language such as "call get_showtimes first to obtain session_id" — the dependency is only implied by naming where IDs come from.

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

All Cinve tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.