Skip to main content
Glama

What can be made next

character_next
Read-only

Lists completed character-production steps and priced next options—concept, location, video, voice, music, translations—so users can choose what to generate next; paid steps run only after a yes.

Instructions

Free. Use when the user asks what's next for a character: lists what is done and the next possible steps (concept → location → video → voice, music after the location, translations), with prices. Offer them; run paid ones only after a yes.

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": {
      "id": "<id>"
    },
    "name": "character_next"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description adds the cost trait ('Free'), the fact that paid steps exist and must be confirmed, and, since there is no output schema, the shape of the return (completed items, next steps, prices). It does not cover failure modes for an unknown id, but the added behavioral context is substantial.

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?

Front-loaded with the most decision-relevant facts ('Free', the trigger condition), then the return content, then the follow-up rule. Every clause carries information; the parenthetical pipeline is dense but earns its space.

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?

For a simple read-only tool with one parameter and no output schema, the description covers what comes back and how to act on it. The only real hole is the meaning of the `id` input, which neither schema nor description explains.

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

Parameters2/5

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

Schema coverage is 0% for the single required `id` parameter, and the description never says what it is (a character id), what form it takes, or what happens if it is omitted. With low coverage the description was expected to compensate and does not.

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 uses a specific verb and resource ('lists what is done and the next possible steps' for a character) and enumerates the pipeline stages (concept → location → video → voice, music, translations), which lets an agent distinguish this from the creation/cost siblings without opening a schema.

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?

It gives an explicit trigger ('Use when the user asks what's next for a character') and even prescribes the follow-up flow: offer the steps, and only run paid ones after a yes. It does not say when to prefer character_costs or character_check instead, which is the remaining gap.

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