Skip to main content
Glama
rollecode

IMDb MCP server

by rollecode

search_titles

Read-onlyIdempotent

Find films, series, or episodes by name and retrieve their IMDb tt IDs for use with other title tools. Search by full or partial title and filter by movie or TV.

Instructions

Find films, series and episodes by name.

Start here to get the tt id every other title tool needs.

Args: query: Title, or part of one. title_type: any, movie or tv. limit: How many matches to return.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
title_typeNoany

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds workflow context (this yields the tt id consumed by other tools), which is genuinely useful, but says nothing about result ordering, default page size behavior, or matching semantics (fuzzy vs prefix).

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

Conciseness5/5

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

Two front-loaded sentences establish purpose and routing before any parameter detail, and the args block is terse with no filler. Nothing could be cut without losing information.

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 described, and for a simple 3-parameter read tool the entry-point framing plus per-param notes are close to sufficient. Missing edge detail (max limit, tie-breaking/ranking) keeps it just short of complete.

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?

Schema coverage is 0%, so the description must carry the full parameter burden and largely does: it explains that query accepts a title or partial title, and supplies the title_type values ('any, movie or tv') that the schema does not enumerate. Only limit is left thin—'How many matches to return' gives no default or ceiling.

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 ('Find films, series and episodes by name'), which cleanly separates it from search_names and the get_title_* retrievers. It does not explicitly contrast with advanced_title_search, the closest sibling, so the differentiation is implied rather than stated.

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?

'Start here to get the tt id every other title tool needs' is a clear positive routing instruction that tells the agent this is the entry point in the tool chain. However, it names no exclusions and does not mention advanced_title_search for more complex filtering, so the when-not side is absent.

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