Retrieve the schema for Radarr custom formats to see available fields and structure for creating or editing them. Use this to understand valid properties and define custom format rules.
Read CustomFormat.
GET /api/v3/customformat/schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe, non-mutating nature is clear. The description's 'Read' aligns with those annotations and adds no additional behavioral context such as authentication requirements, rate limits, or empty-result behavior. The output schema covers return structure, so the description does not need to explain response fields.
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 very concise: a two-line phrase plus endpoint. There is no wasted text, and the core action is front-loaded. However, the first line is slightly imprecise and could have said 'Read CustomFormat schema' instead of 'Read CustomFormat', which would make the purpose unmistakable without adding bulk.
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?
For a zero-parameter read-only tool with a rich output schema and safety annotations, the description covers the basic call. However, it does not explain why one would call this schema endpoint, how it relates to create/update workflows, or how it differs from simply listing custom formats. The missing usage context leaves the agent to infer the tool's role from the name and endpoint alone.
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?
The input schema has zero parameters, so there is no parameter semantics to document. The description consistently implies a simple GET request with no inputs, matching the empty parameter schema. With 0 params, the baseline of 4 applies and no deduction is needed.
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 reads 'Read CustomFormat.' and provides the endpoint. The verb and resource are present, but the tool's actual function—retrieving the schema for CustomFormat—is only implied by the endpoint URL and the tool name, not stated in the prose. This leaves ambiguity with sibling tool list_customformat, which may have an almost identical one-line description.
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?
There is no guidance about when to use this tool instead of list_customformat or the other list_*_schema tools. The description does not mention typical use cases such as discovering custom format fields before creating or updating a custom format. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.