Skip to main content
Glama
wsqreis
by wsqreis

Movie details

get_movie_details
Read-onlyIdempotent

Fetch complete details for one TMDB movie by ID, including runtime, genres, score, directors, writers, top cast, budget, revenue, and trailer.

Instructions

Full details for one movie in a single call: runtime, genres, score, directors, writers, top cast, budget, revenue and trailer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
movieIdYesTMDB movie id (from search_movies or discover)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
titleYes
votesYesNumber of TMDB votes behind the score
genresYes
imdbIdYes
ratingYesTMDB user score, 0-10
taglineYes
topCastYes
writersYes
overviewYes
budgetUsdYes
directorsYes
revenueUsdYes
trailerUrlYes
releaseDateYes
runtimeMinutesYes
originalLanguageYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower; the description adds useful context by listing the concrete fields returned and noting it is a single-call operation. It does not mention auth needs, rate limits, or trailer availability caveats, so it stops 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?

One front-loaded sentence with no filler, leading with the core purpose before the field list. The field enumeration is slightly list-heavy but each item is informative rather than padding.

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 single-parameter read tool with an output schema and full annotation coverage, the description is essentially sufficient: purpose, scope and returned content are clear. The only gap is the absence of routing guidance relative to sibling tools.

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?

There is one parameter and schema description coverage is 100%: the schema already documents movieId as a TMDB id sourced 'from search_movies or discover'. The description adds no additional parameter meaning, so the baseline 3 applies.

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+resource ('Full details for one movie') and enumerates exactly what is returned. The resource type ('movie') cleanly separates it from siblings like get_tv_show_details and get_person_details without needing to name them.

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 only implied: 'Full details for one movie in a single call' suggests using it when you already have a movieId and want everything at once. There is no explicit when-to-use, when-not, or alternative routing (e.g., versus calling several smaller endpoints).

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