Rollekino MCP server

Official

Overview Schema Source Related Servers Discussions Admin

list_films

Read-onlyIdempotent

Filter and sort films in the Rollekino archive by year, genre, director, actor, rating, or status to find specific entries.

Instructions

List films, filtered and ordered.

Args: year: Release year, as the archive records it. genre: Genre name in Finnish, such as Komedia or Draama. director: Director's name. actor: Actor's name. min_rating: Only films Rolle rated at least this, 1 to 10. max_rating: Only films he rated at most this, 1 to 10. unrated: True for films with no rating yet. imdb: IMDb id, to find one specific film. status: publish, draft, or any. orderby: date, title or rating. order: ASC or DESC. page: Which page of results. per_page: Results per page, at most 100.

Input Schema

TableJSON Schema

Name	Required	Default
`imdb`	No
`page`	No
`year`	No
`actor`	No
`genre`	No
`order`	No	DESC
`status`	No	publish
`orderby`	No	date
`unrated`	No
`director`	No
`per_page`	No
`max_rating`	No
`min_rating`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.1Sep 30, 2026

addedInput schema / properties / imdb

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

addedInput schema / properties / status

Added value: +{
+  "default": "publish",
+  "title": "Status",
+  "type": "string"
+}

First observedv1.0.0Sep 18, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered by structured data. The description adds no behavioral context beyond that - it says nothing about pagination behavior, filter combination rules, or default handling, and an output schema exists to cover returns.

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 one-line summary is front-loaded and the arg list is terse with no filler. It is long only because 13 parameters genuinely need documenting, though indentation of the Args block is slightly wasteful.

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?

With an output schema present, return values need not be explained, and the 13 parameters are fully described. The remaining gap is the absence of routing guidance against the four sibling find/search/get tools, which matters given this is a heavily filtered listing endpoint.

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: it documents every one of the 13 parameters, including enum-like values for orderby/order/status, the 1-10 rating bounds, the Finnish-language genre convention, and the per_page cap of 100. This is exactly the compensation needed for an undocumented schema.

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?

States a specific verb and resource ('List films') plus the scope modifier 'filtered and ordered', which is immediately actionable. It does not, however, differentiate itself from the sibling 'search_films' or 'find_film', leaving the agent to guess which listing/finding tool to pick.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all: nothing explains when to call list_films versus search_films, find_film, or get_film, nor whether filters combine with AND semantics. The agent must infer usage entirely from the parameter list.

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

Deploy Server