List export jobs for a model by owner/project/model, ul:// URI, or slug with project to track export status.
List export jobs for a model by owner/project/model, ul://owner/project/model, or slug with a project.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ref by owner/project/model, ul:// URI, or slug (requires project). | |
| project | No | Project ref required when model is given by slug. |
Changes observed during successful MCP inspections.
v0.1.15Input schema / additionalPropertiesAdded value: +falsev0.1.12Input schema / properties / model / descriptionPrevious value: -"Model id, or slug when project is also provided."New value: +"Model ref by owner/project/model, ul:// URI, or slug (requires project)."Input schema / properties / project / descriptionAdded value: +"Project ref required when model is given by slug."v0.1.6Input schema / properties / model / descriptionAdded value: +"Model id, or slug when project is also provided."v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds only reference-format details that are already in the input schema, with no extra behavioral context such as pagination, ordering, rate limits, or authorization requirements.
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?
It is a single front-loaded sentence with no redundant or filler content. Every part of the sentence contributes to identifying the operation and accepted model references.
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?
For a simple read-only list tool with full schema coverage and safety annotations, the description is nearly complete: it identifies the resource from the operation and accepted inputs. It omits return-related details, but no output schema exists and those details are not essential for correct invocation.
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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description reiterates the same reference formats but adds no additional syntax, constraints, or semantics beyond what the schema provides.
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?
The description states a specific verb ('List') and resource ('export jobs') and scopes them to a model via supported reference formats. It is clear on its own, though it does not explicitly differentiate itself from siblings like export_status or export_create.
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?
It gives no when-to-use guidance, prerequisites, or alternatives. The agent must infer usage from the listing verb alone, with no routing cues to export_status for a single export or export_create to start one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.