Skip to main content
Glama

Series end card read

series_end_card_read
Read-only

A video series' end card: the short card every episode of the series ends on, the same each time, with one line of the episode's own. Says whether the series ends on its own card or the brand's, whether the owner chose that, its own card and the brand's (made by Marsell or the owner's own video, with a clip or still of each), whether the owner's AI was asked for one, and the series' look, tone and accounts (what a card made for it follows). Without series, every video series. A series made as a show of its own makes its own card with its first episode; the business's own channel and the series setup made end on the brand's card until the owner gives them their own. Reading spends nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "series_end_card_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
seriesNoThe series' id or exact name. Leave out when the business has one video series.
projectNoThe project's id or exact name. Optional when the account has one project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnly, non-destructive and closed-world, so the safety bar is covered. The description still adds real value beyond them: 'Reading spends nothing' discloses cost, and the sentence about default scope tells the agent what happens when the optional parameter is omitted. No return format or pagination detail, but a read of this shape needs little.

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

Conciseness2/5

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

The whole definition is a single sprawling run-on sentence with stacked parentheticals ('made by Marsell or the owner's own video, with a clip or still of each'), and the core statement of what is returned is not front-loaded. The domain lore about first episodes and brand cards consumes a large share of the text without helping the agent call the tool.

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 no output schema, the description carries the return burden and does enumerate the returned facts in reasonable detail, plus the default scope when `series` is omitted. Only the absence of any routing hint against sibling read tools keeps it from being fully 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 100%, so baseline is 3. The description goes further by stating that omitting `series` returns every video series, which sharpens the schema's vaguer 'leave out when the business has one video series' into an explicit default. `project` gets no description-level treatment, but the schema already covers it.

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?

The resource is identified precisely ('A video series' end card') and the description enumerates the specific facts returned (which card the series ends on, ownership choice, both cards, AI request, look/tone/accounts). That is enough to tell it apart from a generic card tool, but it never states the action in a leading verb+resource clause, so the purpose has to be assembled from a field list rather than read off the first line.

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

Usage Guidelines2/5

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

The only usage-relevant sentence is 'Without series, every video series,' which gives a default scope. The rest is domain background about how end cards are produced (show-of-its-own vs. business channel), not guidance on when to call this versus siblings like card_read, series_read, or business_context_read.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.