Orca MCP

tv_episodes

Read-onlyIdempotent

Episode list for a TV series: season/episode numbers, titles, airdates, summaries. Use for 'breaking bad season 2 episodes' style questions. For one season with ratings and stills use tv_season, for a single episode with guest stars use tv_episode. Series only - do NOT use for movies.

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": {
      "query": "<query>"
    },
    "name": "tv_episodes"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Episodes to return, 1-50 (default 20).
`query`	Yes	Show title, e.g. 'breaking bad' (required).
`season`	No	Filter to one season number.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 15, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful context about what the list contains (season/episode numbers, titles, airdates, summaries) and the series-only scope. It doesn't disclose pagination or limit behavior beyond the schema, but the annotations carry the main behavioral burden.

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?

Three sentences, all information-dense. The core purpose is front-loaded, followed by sibling routing and a scope exclusion. No wasted words.

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

Completeness5/5

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

For a read-only list tool with full schema coverage and strong annotations, the description is complete. It covers what the tool returns, when to use it, when not to use it, and the series-only constraint. No output schema exists, but the description already names the return fields (season/episode numbers, titles, airdates, summaries).

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 the schema already documents all three parameters. The description adds a concrete example query ('breaking bad') and clarifies the query is a show title, which reinforces the schema. It doesn't add new parameter semantics beyond that, so baseline 3 is appropriate.

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?

The description states a specific verb and resource: it returns an episode list for a TV series, with season/episode numbers, titles, airdates, and summaries. It clearly distinguishes itself from siblings tv_season and tv_episode by naming them and their specific use cases.

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

Usage Guidelines5/5

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

The description explicitly says when to use this tool ('breaking bad season 2 episodes' style questions), and explicitly says when NOT to use it: for one season with ratings/stills use tv_season, for a single episode with guest stars use tv_episode. It also warns 'Series only - do NOT use for movies.' This is exemplary routing guidance.

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

All Orca MCP 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?