---
name: diagnose-import
description: Diagnose failed, stale, or unexpectedly empty Dotidot data-source imports and identify affected feed exports. Use when a user asks why a Dotidot feed is not updating, why its import failed, or which data sources are failing.
---

# Diagnose a Dotidot import

Use the connected Dotidot MCP server to establish the current import problem, its evidence, and the next useful action. This workflow investigates; it does not change the account.

## Establish access and scope

- Use the host's available tool schemas. Names below are the server's base names; the host may prefix them. Discover arguments from those schemas instead of inventing request fields.
- If Dotidot tools are unavailable or authentication fails, direct the user to connect `https://mcp.dotidot.io/mcp` and sign in through their client's OAuth flow. Connection instructions are at https://mcp.dotidot.io. Resume after authentication; do not infer account health from a connection error.
- When identity or organization is unclear, use `whoami` and `list_organizations`. Reuse an organization the user already selected. If multiple organizations could match, resolve that ambiguity before inspecting their feeds.
- Resolve the requested source with `list_data_sources`, retaining its returned ID and hierarchy. If the user asks which sources are failing, inspect the requested organization's source inventory and prioritize sources whose returned status indicates a problem. Follow pagination when available; disclose an incomplete inventory.
- Resolve ambiguous source names before diagnosing a particular source. If a source is grouped or filtered from another source, inspect the returned parent relationship when it could explain the failure.

## Establish the cause

Start with `get_data_source` and `list_data_source_import_runs`. Compare the current state with the most recent failed and successful runs available.

- Read source status and import health separately. `status: running` alone does not prove a successful import; check `importStatus`, `importSyncInProgress`, and the timestamps. A paused source may explain missing recent activity, but does not explain an older download error.
- An empty bounded history or `last_run: null` does not prove that the source never imported. Compare available import timestamps, report that the run evidence is unavailable, and leave the exact cause unresolved rather than inventing one.
- For a failed import, use `get_data_source_import_diagnosis`. It concerns the newest import; do not present it as the cause of an older failure unless the timestamps and returned evidence support that connection. Include duplicate product IDs when the tool identifies them as relevant.
- Use `list_data_source_incidents` for additional evidence. Historical incidents alone do not establish that a problem is still active.
- For an apparently stale import, use `get_data_source_import_settings` to compare the configured schedule with observed run timestamps. Preserve the timezone supplied by the tools and say when it is unknown. Do not invent an overdue threshold or assume every source imports hourly.
- For unexpected product counts, compare only counts and runs actually returned. Use `get_data_source_settings` when source filtering or empty-import behavior could explain the result. An empty feed alone does not prove a failed import.
- Inspect enrichment or connected-source details only when the evidence points there, using the available read tools. Distinguish confirmed causes from hypotheses and identify the missing evidence when no cause is established.

## Assess the relevant downstream effect

When the user asks about exports or downstream impact, use `list_feed_exports` and the returned source relationships to find relevant exports. For a suspect export, use `get_feed_export` and `list_feed_export_generation_runs`. Distinguish an import failure from a separate export-generation failure; do not assume every dependent export is broken.

## Report and hand off

Respond in the user's language. Identify the organization and source, summarize current health, cite the relevant run timestamps and errors, and give the next action supported by that evidence. Include returned IDs or application links where useful; do not fabricate links. State any unavailable tools, missing history, or incomplete inventory that limits the diagnosis.

Do not change a feed URL, mapping, schedule, or export to test a hypothesis or trigger an import. A URL change can re-import data and affect live campaigns and exports. If the user requests a repair, separate the diagnosis from the proposed concrete change and its downstream effects, then follow the user's authorization and the host's write-confirmation controls. Never claim that a recommended repair has already run.