Rollekino MCP server

Official

Overview Schema Source Related Servers Discussions Admin

create_film

Idempotent

Add a film to the Rollekino archive enriched with TMDB details like plot, cast, and ratings. Automatically reuses existing entries instead of creating duplicates.

Instructions

Add a film to the archive, enriched from TMDB.

With tmdb_id the site fetches plot, poster, backdrop, cast, crew, genres, trailer, IMDb and Metascore exactly as the quick review page does. Find the id with lookup_tmdb.

The archive keeps one entry per film. If this one is already there, nothing is created and the existing entry comes back instead: update that with update_film or write_review rather than adding a second.

Args: title: Film title, usually the Finnish release title if it has one. tmdb_id: TMDB id, from lookup_tmdb. Strongly preferred. rating: Rolle's own rating: whole number 1 to 10, 0 for not rated. This is the archive's native scale, so never convert from IMDb or Metascore. If he gives stars out of 5, double them. date: Date shown on the review, YYYY-MM-DD or YYYY-MM-DD HH:MM, Helsinki time. Use the day he watched it, which Trakt history records, not today. content: His review text. Leave empty rather than writing one for him. status: draft or publish. imdb_url: Full IMDb URL, when there is no tmdb_id. year: Release year, when there is no tmdb_id. plot: Finnish synopsis, when there is no tmdb_id. allow_duplicate: Create even if the film exists. Almost never right.

Input Schema

TableJSON Schema

Name	Required	Default
`date`	No
`plot`	No
`year`	No
`title`	Yes
`rating`	No
`status`	No	draft
`content`	No
`tmdb_id`	No
`imdb_url`	No
`allow_duplicate`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.1.1Sep 30, 2026

addedInput schema / properties / allow_duplicate

Added value: +{
+  "default": false,
+  "title": "Allow Duplicate",
+  "type": "boolean"
+}

addedInput schema / properties / date

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Date"
+}

changedInput schema / properties / rating / anyOf

Previous value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv1.0.0Sep 18, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare idempotency and non-destructiveness, but the description adds the crucial behavioral detail the annotations only imply: the archive keeps one entry per film and returns the existing entry rather than creating a duplicate. It also discloses what enrichment fetches from TMDB, which no structured field conveys.

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?

Front-loads purpose, enrichment, and the dedup warning before the Args block, so the most important agent-facing facts come first. Slightly redundant in repeating lookup_tmdb twice, but every sentence is functional and earns its place.

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 values needn't be explained, and the description still notes that an existing entry comes back instead. For a 10-param mutation tool with 0% schema coverage, the definition leaves nothing an agent needs missing.

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?

Schema description coverage is 0%, so the description carries the full burden and does so thoroughly for all 10 params: rating scale rules (1-10, 0 unrated, never convert from IMDb, double out of 5), date format with timezone and source, the leave-content-empty rule, status values, and the tmdb_id-vs-imdb_url fallback group.

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?

States a specific verb and resource ('Add a film to the archive') plus the enrichment source (TMDB), which immediately distinguishes it from siblings like update_film and write_review. An agent can tell what this creates without opening the schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: use lookup_tmdb to find the id, prefer tmdb_id over imdb_url, and use update_film or write_review instead when the film already exists. It even flags that allow_duplicate is 'almost never right', giving clear when-not guidance.

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

Deploy Server