Skip to main content
Glama
Sign In
rollecode

Rollekino MCP server

Official
by rollecode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

write_review

Idempotent

Add or replace a review in the Rollekino film archive using supplied text, rating, date, and publish status; submit Rolle's own wording, not generated copy.

Instructions

Put Rolle's review text on a film.

The text is his: pass what he wrote, never compose one for him.

Args: id: Film id. content: The review, as HTML or plain paragraphs. Replaces what is there. rating: Whole number 1 to 10. See create_film. date: Date shown on the review. See create_film. publish: True moves a draft to published.

Input Schema

NameRequiredDescriptionDefault
idYes
dateNo
ratingNo
contentYes
publishNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.1
    • 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"
+  }
+]
  2. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

Description adds real behavioral context beyond annotations: content 'Replaces what is there' (overwrite semantics on an idempotent write) and the authorship constraint that the review text must be the user's, not agent-composed. Annotations already cover safety (readOnly=false, idempotent=true), so this extra guidance is credited. Minor tension between field replacement and destructiveHint=false, but replacement within a record is not the resource-level destruction the hint describes.

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 line, followed by the useful authorship directive and a compact Args list. The docstring formatting is slightly verbose but each line adds information; nothing is wasted.

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?

For a 5-parameter mutation tool with annotations covering the safety profile and an output schema covering returns, the description is complete enough to call correctly. The only shortfall is that rating/date semantics point to a sibling tool rather than being self-contained.

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?

With 0% schema description coverage, the description carries the full burden and documents all five parameters: id (film id), content (HTML or plain paragraphs, replaces existing), rating (whole 1-10), date (shown on review), publish (draft->published). It defers exact rating/date formatting to create_film, which is a minor gap but keeps semantics clear.

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 ('Put Rolle's review text on a film'), which cleanly identifies this as writing a review to an existing film record. It doesn't explicitly contrast with update_film or create_film, so the agent must infer the boundary, but the action itself is unambiguous.

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?

Usage is implied through parameter hints ('publish: True moves a draft to published', 'See create_film' for rating/date formats), which tells the agent how to invoke it but not when to choose it over update_film or set_rating. No explicit exclusions or alternative routing.

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

Deploy Server

Other Tools