TMDb — Get movie details

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

No annotations are provided, so the description carries the full burden. It doesn't disclose what details are returned, whether append_to_response enables sub-resources like credits, videos, or reviews, what API behaviors to expect (rate limits, auth), or how the data is structured. For a fetch tool this is a moderate gap — the read-only nature is implied but nothing else is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with zero waste. It front-loads the primary purpose and names the optional parameter accurately. Very concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple 2-parameter get-by-id tool, the description is mostly adequate. However, with no annotations, no output schema, and 0% schema coverage, it could usefully mention that append_to_response accepts comma-separated TMDb sub-resource names and that the response contains standard TMDb movie fields. It's functional but leaves the append_to_response mechanism underspecified.

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

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

Schema description coverage is 0%, meaning neither the schema nor the description explain what 'id' refers to (TMDb internal ID format, type) or what values append_to_response accepts (comma-separated sub-resources like 'credits,reviews'). The description names append_to_response but doesn't explain its format or possible values, so it adds marginal value over the raw parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get TMDb movie details by id with optional append_to_response,' which is a clear verb+resource pairing that specifies the input mechanism (id) and an optional extension. It distinguishes from siblings like film_omdb_get (different source) and film_tmdb_search_movie (search vs retrieval), though it doesn't explicitly name alternatives.

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

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

The description implies when to use this tool — when you already have a TMDb movie id and need full details — but doesn't explicitly state when not to use it or name the sibling search tool as the alternative for when you lack an id. The context is reasonably clear but lacks explicit exclusions or alternative references.

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