investigate-tdarr-job

Investigate a Tdarr Job

Keep the investigation read-only. Do not requeue jobs, change flows, delete reports, or modify Tdarr configuration unless the user explicitly asks.

Verify the Tdarr MCP server

Complete this preflight before selecting or fetching a job:

1. Inspect the tools available to the current agent. Resolve tools by their HTTP method and path or operation name; do not depend on a host-specific namespace prefix such as mcp__tdarr__.

2. Confirm these operations are available before proceeding:

   • Always: GET /api/v2/status and GET /api/v2/job-reports/{jobId}.
   • When the user did not supply a JobId: POST /api/v2/client/{clientType} and POST /api/v2/crud/db.
   • Optional report fallback: GET /api/v2/job-reports/{jobId}/download.

3. If a required operation is unavailable, stop and list the missing operation or operations. Tell the user that the agent needs access to an active tdarr-mcp server exposing those tools.

4. Call the read-only status operation. For agents that expose the server-qualified generated tool name, the call is:

   mcp__tdarr__GET_apiv2status()
   

5. Proceed only when the call succeeds. If the MCP endpoint cannot be reached, stop and report that the tdarr-mcp server is inactive or unreachable. If the MCP call reaches the server but the Tdarr API request fails, stop and report that the MCP server's Tdarr connection or credentials need attention. Preserve the concrete error in either case.

Select the job

If the user supplies one or more JobIds, investigate them directly.

If no JobId is supplied:

1. Query the Tdarr UI failed-transcode table:

   mcp__tdarr__POST_apiv2clientclientType({
     clientType: "<verified Tdarr client type>",
     data: {
       start: 0,
       pageSize: 100,
       filters: [],
       sorts: [],
       opts: { table: "table3" }
     }
   })
   

2. Obtain the exact clientType from the server/API implementation or a known working UI request. Never invent it.