Update to Tamarind Bio

{
  "name": "tamarind-mcp-results-analysis",
  "description": "Recover and analyze an existing Tamarind Bio job or batch through MCP by durable name, including bounded monitoring, logs, metrics, output-file inspection, cancellation, and downstream artifact selection. Use after submission or across sessions. Not for starting a new job or using the CLI.",
  "included_files": [],
  "skill_md_contents": "---\nname: tamarind-mcp-results-analysis\ndescription: Recover and analyze an existing Tamarind Bio job or batch through MCP by durable name, including bounded monitoring, logs, metrics, output-file inspection, cancellation, and downstream artifact selection. Use after submission or across sessions. Not for starting a new job or using the CLI.\n---\n\n# Recover Tamarind MCP results\n\nTreat the durable job or batch name as the recovery key. Never create a replacement merely because the original client task ended.\n\n## Recover state\n\n- Single job: call `getJobs(jobName=...)`.\n- Batch or pipeline: call `getJobs(batch=..., includeSubjobs=true)` and, when present, inspect its parent row separately by name.\n- Active work: poll `getJobs` at 15-30 second intervals through a bounded client wait/session. Stop at a finite deadline and report the current state.\n- Failed work: call `getJobLogs(jobName=..., maxLines=200)` and explain the actionable failure without automatically resubmitting.\n\nParse score fields defensively. Report only metrics actually present, say whether higher or lower is better, and distinguish confidence or computational affinity from experimental validation.\n\n## Inspect outputs\n\nCall `listJobFiles` first. Select files by evidence from the listing, not an assumed filename.\n\n- Use `getJobFile` for targeted text, structures, tables, configs, or other files within its size limit.\n- Use `getResult` only when the complete result archive is required. Treat its presigned URL as sensitive and do not quote it back to the user.\n- For a downstream stage, prefer the exact `s3Path` returned by `listJobFiles` when the next live schema accepts it. Otherwise retrieve the artifact and re-upload it with `uploadFile`.\n\nFor structures, inspect local/global/interface confidence separately when present. Reject obviously malformed geometry and require independent structural validation before recommending a candidate. For design or docking outputs, preserve diverse candidates and do not optimize on one scalar score alone.\n\n## Cancel or delete\n\nBoth operations are consequential. Resolve the exact durable target with `getJobs` first.\n\n- Use `cancelJob` for one active job and `cancelBatch` for a batch or pipeline. Cancellation preserves rows and outputs.\n- Use `deleteJob` only after explicit confirmation that the exact named job or batch should be permanently removed.\n- Use `deleteFile` only after confirming the exact file or folder. Folder deletion is bulk deletion.\n\nNever substitute a similarly named target, expand a wildcard, or delete active work unless the user explicitly includes it.\n\n## Report\n\nReturn the durable name, current or terminal status, subjob counts when applicable, weighted hours and scores when present, inspected artifacts, analysis limits, and a precise downstream handoff if requested.\n"
}