Skip to main content
Glama
minghsuy

ctscout

by minghsuy

Poll a deep-dive job and read its result

ctscout_get_job
Read-onlyIdempotent

Check the status of a submitted deep-dive job and retrieve its attribution results once complete. Poll until done to get the attribution table with confidence bands, signals, and evidence.

Instructions

Read the state of an asynchronous Pro deep dive submitted with ctscout_submit_deep_dive, via GET /jobs/{id}. Read-only and free to repeat: polling debits no quota.

Polling:

  • status is "queued" | "running" | "done" | "failed". Only "done" carries "result"; "failed" carries a short "error".

  • Back off: about 30 s before the first poll, then longer waits up to 5 min. A deep dive runs on a batch worker that picks up queued jobs every few minutes.

  • Pro only, and job ids are scoped to the submitting key: HTTP 404 means not your job or an unknown id.

Args:

  • job_id (string, required): the id returned by ctscout_submit_deep_dive.

  • response_format ('markdown' | 'json', default 'markdown'): output format.

Returns (on success, structuredContent follows the declared outputSchema; a failed call — 401, 403, 404, timeout — is isError with no structuredContent, so never dereference snapshot on a failed call):

  • In markdown: the job status lines; once done, the deep-dive attribution table (domain, attributed to, confidence band, signals, evidence) under a snapshot line. No /scan output carries this table.

  • In JSON, structured as: { "job_id": string, "kind": "deep_dive", "status": "queued" | "running" | "done" | "failed", "submitted_at": string, "started_at": string | null, "finished_at": string | null, "result": { // only when status is "done"; the deep-dive shape (see below), never returned by /scan "entity": {...}, "domains": [ { "domain": string, "attributed_to": string, "enrichment": {...}, "base": {...} } ], "run_metadata": {...}, "source": "live-enriched" | "cache-only", "signals_degraded": boolean, "snapshot": string, // warehouse date (YYYY-MM-DD) the deep dive read from — present, the batch worker sets it "worker_version": string, "signals_attempted": ... }, "error": string, // only when status is "failed" "snapshot": string | null, // copy of result.snapshot once done; null (unknown) before that "snapshot_source": "scan" | "unavailable" // 'scan' = the API response carried the date }

  • "Attributed" means the organization is what the evidence names for that domain, not an ownership claim. "Candidate" means a semantic name-similarity guess that is NOT an attribution. Deep dives return attributions with a confidence band (verified / likely / possible / insufficient), never bare candidates. When "signals_degraded" is true some signals errored: absence of their evidence is not evidence of absence.

  • Visual brand verification (VLM) is NOT included in v1: vlm_status stays "pending" or "skipped" and never vetoes a band.

Examples:

  • Use when: "Is my deep dive abc123 finished?" -> { job_id: "abc123" }

  • Don't use when: you have no job_id — submit first with ctscout_submit_deep_dive, or use the synchronous tools.

Corrections:

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesThe job_id returned by ctscout_submit_deep_dive.
response_formatNoOutput format: 'markdown' for the job status and, once done, the deep-dive attribution table (band, signals, evidence); 'json' for the raw job record.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo'deep_dive'.
errorNoShort 'type: message' reason, present only when status is 'failed'.
job_idYes
resultNoPresent only when status is 'done'.
statusYes'queued' | 'running' | 'done' | 'failed'.
snapshotYesWarehouse/D1 sync date (YYYY-MM-DD) the answer was read from; the warehouse syncs daily. null when the API could not determine it.
started_atNo
finished_atNo
submitted_atYes
snapshot_sourceYes'scan' = the API response carried the date; 'unavailable' = it did not, snapshot is null and must be treated as unknown, never as current.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Extremely transparent about behavior: status values, polling intervals, error handling, no structuredContent on failure, snapshot_source semantics, attribution vs candidate meaning, signals_degraded implications, and VLM exclusion. Annotations are consistent and the description adds substantial behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well structured with clear headings (Polling, Returns, Examples, Corrections), but it is quite verbose. The length is justified by the complexity of the async result shape and semantics, so it remains effective despite being detailed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides a complete picture for a complex asynchronous tool: full status lifecycle, output shape in both markdown and JSON, success/failure behavior, snapshot handling, attribution caveats, example usage, and correction channels. Nothing an agent needs to call and interpret this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes both parameters with high coverage, and the description reinforces job_id origin and response_format output differences. The extensive Returns section adds meaningful semantics beyond the schema, though the schema alone is already quite clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it reads the state of an asynchronous deep-dive job and retrieves its result, with the specific verb 'Read' and the resource 'job'. It also distinguishes itself from submission and synchronous tools by naming them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use and don't-use guidance: use when you have a job_id, don't use without one, and directs to submit or synchronous alternatives. Also explains polling backoff and when to expect completion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.