Retrieve full status and error details for an import job, including progress and row counts for imported, skipped, and failed records.
Get full status and details of an import job including progress, row counts (imported, skipped, failed), and error details.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Import job ID | |
| companyId | No | Company UUID override (uses active company if not set) |
Changes observed during successful MCP inspections.
v1.0.17Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds real value by enumerating what the response contains (progress, imported/skipped/failed row counts, error details), which is important since there is no output schema.
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?
A single front-loaded sentence with the verb and resource first and the returned fields after; no filler or repetition.
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?
With no output schema, the description appropriately describes the returned data, and annotations cover safety. What's missing is call-sequence context (e.g., use after import_execute to poll progress), which would fully round it out.
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?
Schema coverage is 100%: both id and companyId are documented in the schema, including the active-company fallback behavior. The description adds nothing about parameters, so the baseline 3 applies.
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?
States a specific verb (get) and resource (import job) plus the scope of what is returned (status, progress, row counts, error details). It is distinguishable from import_execute/import_upload, though the boundary with import_history is only inferable, not stated.
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?
The description gives no indication of when to call this versus import_history (list jobs) or when to poll it relative to import_execute. An agent must infer that this retrieves a single job by ID and that import_history lists them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.