Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@imsdbMCP Recap Inception up to the scene where they wake up on the beach."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives an LLM the tools to catch you up on a movie you joined partway through. Describe the scene you're at, and it recaps everything before that point with no spoilers for what comes after.
You give the LLM a movie title and a description of where you are.
movie_matcher checks the SQLite cache. If the movie isn't there, it scrapes the script from IMSDb, splits it into scenes by detecting INT./EXT. headings, writes a one-line summary of each scene with Claude, and stores everything.
movie_matcher returns the scene summaries, and the LLM picks the scene that matches your description.
summary_to_full returns the full text of every scene up to that point, and the LLM writes the spoiler-free recap.
Related MCP server: Movie Search MCP Server
The summaries are cached to reduce the amount of API calls. Each scene requires an API call to be summarized, so by caching them, we can reduce the API calls the second time a movie is asked about by the amount of scenes in the movie (often 90+). This also increases speed of the response.
Matching is done by the LLM, not code. Viewers describe a scene in their own words and notice different details, so there's rarely a word-for-word match. Fuzzy matching is what an LLM does well.
One shared SQLite table. A new movie is new rows, not a new table. Separate tables would mean generating table names from movie titles at runtime.
Install uv and run uv sync.
Create a .env file with ANTHROPIC_API_KEY=your-key (requires API credits).
Test with the MCP Inspector: uv run mcp dev server.py (needs Node.js).
To use with Claude Desktop, add this to claude_desktop_config.json:
{
"mcpServers": {
"imsdb-recap": {
"command": "/path/to/uv",
"args": ["run", "--directory", "/path/to/this/repo", "server.py"]
}
}
}Pariah parses to 91 scenes, not the script's 88 numbered ones. Lettered scenes (84A, 84B) are counted separately, and one extra heading wasn't traced. Scene numbers are this tool's own count, not the script's printed numbers, and matching works on those.
The titles of the movie must match what IMSDb has, or the LLM must be able to check for multiple possible matching names. For example, 'The Back-Up Plan' is 'Back-Up Plan, The' in the database. However, the LLM in testing has been able to find the right movie.
As well, the first run for a new movie makes about 90 API calls, so it can take over a minute. Some MCP clients time out, so run the Inspector with a longer timeout for the first request.
To run, this product needs paid Anthropic API credits.
Scripts that don’t use INT./EXT. headings won’t parse.
Coverage is limited to what IMSDb has.
Cache keys are case-sensitive.
Scripts are copyrighted and come from IMSDb. The tool uses them as source material: scene text is passed to the LLM to write recaps, and users receive the recap, not the script. movies.db is gitignored, so no script text is in the repo.
Allow the user to tell the LLM the timestamp so they don't have to describe the scene.
Add in new database sources other than IMSDb, so there can be more movies + shows.
This tool uses the movie title to get all scene summaries. Use to find where the user is in the movie.
| Name | Required | Description | Default |
|---|---|---|---|
| movie_title | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb "get" implies a read-only lookup and the intent sentence adds locating context, but nothing is said about title matching behavior (exact vs. fuzzy), what happens when the title is unknown, or how large the returned scene set may be.
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?
Two short sentences, front-loaded with the action and followed by the intent. The phrase "uses the movie title to" is slightly wordy but nothing here is filler or redundant.
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?
The tool is simple: one required string parameter and an existing output schema that documents the returned scene summaries. Given that return values are covered elsewhere and the operation is a trivial read, the description supplies enough for correct invocation, with only matching semantics as a residual gap.
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?
There is one parameter with 0% schema description coverage, so the description must compensate. It does establish that movie_title is the lookup key for retrieval, but it adds no constraints on format, casing, or matching tolerance beyond the parameter name itself.
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?
States a concrete verb-plus-resource: retrieves all scene summaries for a given movie title. The purpose is intelligible without opening the schema, but it never acknowledges the sibling tool summary_to_full, so an agent cannot distinguish the two from the description alone.
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?
"Use to find where the user is in the movie" supplies one contextual use case, which is helpful but only implied guidance. There are no exclusion conditions, no mention of when summary_to_full would be preferable, and no prerequisites such as the title needing to match a known film.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool uses the movie title and scene number to get all full scenes from the beginning to scene n, so the LLM can explain the movie up until scene n.
| Name | Required | Description | Default |
|---|---|---|---|
| n | Yes | ||
| movie_title | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. 'Get' implies a read, but it says nothing about permissions, whether the result is truncated for long movies, how the title is matched, or whether n is 1-indexed/inclusive.
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?
One sentence, front-loaded with the operation, with no filler. The trailing 'so the LLM can explain the movie up until scene n' partially restates the range clause, but it adds rationale rather than pure repetition.
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?
An output schema exists, so return values need no explanation. Still, for a tool whose correctness depends on range boundaries and title matching, the description leaves those semantics unstated and does not address the movie_matcher sibling.
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%, so the description must compensate, and it does map both params to meaning ('movie title and scene number'). It stops short of clarifying title-matching behavior (exact vs fuzzy) or whether scene n is included in the returned range.
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?
States a specific verb and resource ('get all full scenes') and bounds the scope to 'from the beginning to scene n'. The intent is clear enough to distinguish it from a title-matching tool, though it never names the sibling movie_matcher to sharpen the contrast.
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?
Gives an implied use case ('so the LLM can explain the movie up until scene n'), which is a genuine context cue. However, it offers no when-not guidance and never mentions movie_matcher as the alternative for finding or disambiguating a title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0movie_matchersummary_to_fullScored across 2 tools
The two tools have mostly distinct outputs: movie_matcher returns scene summaries for a title, while summary_to_full returns full scene text up to a specified scene. They are complementary rather than overlapping, though both operate on movie title and scene data, so an agent may briefly need to reason about which retrieval granularity to use.
Both names use snake_case, but they follow different conventions: movie_matcher is a noun-plus-agent-noun pattern, while summary_to_full is a noun-plus-prepositional phrase. The names are readable but do not form a predictable verb_noun or parallel pattern.
Two tools is thin for a movie-script retrieval server, though each has a clear role in the intended summary-to-full-scene workflow. The surface feels borderline minimal rather than well-scoped.
The core workflow of locating scenes via summaries and then fetching full scenes up to a point is covered. However, there is no movie search or listing operation, so the server may dead-end when the exact title is unknown, and there is no way to retrieve a single specific full scene without fetching from the beginning.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
