Plan explicit remote egress and create fake adapter receipts without network I/O, enabling validation of upload workflows before real transfers.
Plan explicit remote egress and fake adapter receipts without network I/O.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| overwrite | No | Explicitly allow replacing existing media. Existing non-media files are protected. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.16.4Input schema / properties / overwriteAdded value: +{
+ "default": false,
+ "description": "Explicitly allow replacing existing media. Existing non-media files are protected.",
+ "title": "Overwrite",
+ "type": "boolean"
+}v1.16.0Input schema / additionalPropertiesAdded value: +falsev1.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully states that the tool performs no network I/O, but it does not clarify whether the tool writes files, what 'fake adapter receipts' means in terms of output side effects, or how the overwrite parameter affects behavior.
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 front-loaded sentence with no wasted words. Its brevity is appropriate, though the compressed jargon reduces usefulness rather than enhancing it.
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 nested request object, the presence of an output schema, and the absence of annotations, the description is too sparse. It does not explain the expected request structure, the meaning of 'egress' in this video context, or how the tool relates to the many other planning tools in the sibling set.
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 only 50%, with the required nested 'request' object completely undocumented. The description adds no information about what fields belong in 'request' or what 'explicit remote egress' requires, leaving the agent unable to construct a valid request from the description alone.
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 contains a specific verb ('Plan') and resource ('remote egress'), but the phrase 'fake adapter receipts' is undefined jargon that obscures what the tool actually produces. It does not distinguish this planning tool from the many other sibling plan tools such as video_restoration_plan or video_workflow_plan.
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?
There is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only implied usage is the 'without network I/O' clause, which suggests a dry-run planning context, but this is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.