Add a new movie to Radarr by sending the required request payload to the movie API endpoint, using the expected fields from the schema.
Create Movie.
POST /api/v3/movie
Args: body: Request payload. Read the matching GET or the /schema endpoint first to see the fields this resource expects.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal the operation is non-read-only, idempotent, and non-destructive. The description usefully adds that the body is an opaque request payload whose fields must be discovered from the GET/schema endpoint, which compensates for the empty input schema. It does not describe effects, permissions, or error behavior, but the annotations cover the basic safety profile.
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?
The description is short and front-loaded, with the endpoint and argument guidance clearly separated. The opening 'Create Movie.' is somewhat redundant with the tool name, but the rest of the description earns its place.
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?
Given the tool has a single opaque body parameter, a rich output schema, and annotations covering safety, the description is largely sufficient. It tells the agent the critical discovery path (GET/schema) but lacks explicit sibling differentiation and any statement about when manual creation is appropriate.
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. It identifies body as the 'Request payload' and tells the agent where to find the actual accepted fields, which is valuable. However, it does not enumerate or explain any specific body fields, leaving the agent dependent on an external discovery step.
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?
The description states the action ('Create') and resource ('Movie') and provides the specific POST endpoint, so an agent can tell it operates on the movie collection. However, it does not explicitly distinguish this from the sibling create_movie_import, relying on the bare endpoint and resource name.
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?
The only usage guidance is a prerequisite: read the matching GET or /schema endpoint before calling to discover the expected fields. It gives no indication of when to use this tool versus alternatives such as create_movie_import or other create_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.