Boxlist

Title taste profile

get_title_taste_profile

Read-onlyIdempotent

How a film, TV series, book or video game feels, in plain words: its scores on Boxlist's ten taste dimensions (pace, originality, wholesomeness, weightiness, realism, intricacy, linearity, style, scale, emotional punch), its story themes and the Taste Type it suits. For films and TV it adds where to watch in the UK and US; for games, platforms and stores. Use it to explain why someone might or might not enjoy a title.

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": {
      "title": "<title>"
    },
    "name": "get_title_taste_profile"
  }
}

Input Schema

Name	Required	Description
`year`	No	Release year, to tell remakes apart.
`media`	No	Which medium you mean, when the name is shared (e.g. "book" for Dune the novel).
`title`	Yes	A title name ("Succession", "Dune (2021)"), a boxlist.com URL, or a `ref` from another Boxlist tool.

Output Schema

Name	Required	Description
`title`	Yes
`genres`	Yes
`summary`	Yes	One or two plain sentences on how the title feels.
`nextStep`	Yes
`subjects`	Yes
`matchedBy`	Yes
`tasteType`	Yes	Which of the four Boxlist Taste Types this title most suits.
`didYouMean`	Yes
`dimensions`	Yes
`attribution`	Yes	Required credit: show "Data from Boxlist" with the link wherever these results are used.
`storyThemes`	Yes
`whereToPlay`	Yes	Games only.
`whereToWatch`	Yes	Films and TV only: UK and US services.
`dataFreshness`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: it enumerates the exact data returned and notes region-specific availability (UK and US) and game platform/store coverage, which tells the agent what it will and won't get. It stops short of stating behavior on unknown titles or any limits.

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-loaded with the capability, followed by the availability addenda and a single usage sentence. The ten-dimension parenthetical is long but informative rather than filler; nothing here is redundant enough to cut.

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 read-only lookup with an output schema and full parameter documentation, the description is nearly complete — it signals the data domain and per-medium variation. Some of the return-value detail overlaps the output schema, and it omits any note on unmatched titles, leaving a small gap.

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

Parameters3/5

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

Schema description coverage is 100%, so title, year and media are already fully documented, including the year's purpose of disambiguating remakes and the media enum. The description adds only indirect meaning, implying titles span film/TV/book/game. Baseline 3 applies when the schema carries the parameter burden.

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?

The description names the resource concretely — a title's scores on ten named taste dimensions, its story themes, its Taste Type, plus availability (UK/US streaming, game platforms/stores). That is far more specific than a restated title. It does not, however, contrast itself with siblings such as quick_taste_read or find_similar_in_feel, so an agent must infer which one to reach for.

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?

"Use it to explain why someone might or might not enjoy a title" gives a clear intended context for invocation. There are no exclusions and no mention of the lighter-weight alternative quick_taste_read, so the agent is not told when NOT to use this tool.

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

All Boxlist 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.

Resources

Need Help?