Run a delivered package again, on its own data or new data: the same tools, the same curated objects, the same layout, as a new package with its own link.
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | Yes | ||
| dataset_ref | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no behavioral hints (all false), so the description carries the full burden. It discloses that the tool creates a new package with its own link, implying the original package is not modified. However, it does not mention side effects, resource consumption, or whether the operation is idempotent. This is partial transparency but leaves gaps.
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?
The description is a single, concise sentence that front-loads the primary action ('Run a delivered package again') and packs essential details without waste. Every clause adds value, and the structure is clear and scannable.
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?
Given the simple two-parameter schema and lack of output schema, the description covers the core purpose and outcome (new package with its own link). It does not mention prerequisites (e.g., package must be delivered) or error conditions, but for a straightforward rerun operation, it is fairly complete. Minor gaps remain around parameter constraints and execution behavior.
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 0%, so the description must compensate. It hints at dataset_ref by saying 'on its own data or new data,' but does not explicitly map dataset_ref to 'new data' or explain its format. package_id is not mentioned at all, though it is required. The description adds some meaning but does not fully clarify parameter semantics.
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 clearly states the action: 'Run a delivered package again' and specifies the outcome: 'as a new package with its own link.' This distinguishes it from sibling tools like run_analysis or modify_analysis, which serve different purposes. The verb 'run' and resource 'delivered package' are specific and unambiguous.
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 implies the usage scenario: when you want to rerun an existing delivered package, either on its original data or with new data. It does not explicitly mention alternatives or when not to use this tool, but the context is clear enough for an agent to infer the appropriate use case. Lacks explicit exclusions like 'if you need to modify the package, use modify_analysis.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.