Unpack a Power Apps solution zip into a local folder, enabling offline inspection and use as a source for further analysis tools.
Unpack a solution zip (pac solution unpack, local only) into a new folder under the output dir (or /unpacked/). Returns the folder, which works as source= for the offline tools.
| Name | Required | Description | Default |
|---|---|---|---|
| zip_path | Yes | ||
| folder_name | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds useful behavioral details: it creates a new folder under the output dir, returns that folder, and is local-only. It does not cover edge cases like existing folders or failure modes, but it is consistent with destructiveHint=false and openWorldHint=true.
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 compact and front-loaded: the core action appears first, followed by the output path and the return-value usage. Every sentence carries useful information with no filler or redundant restatement.
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 there is no output schema, the description's mention of the returned folder and its role as source= is important and well provided. It does not detail prerequisites or the exact output directory base, but the description is sufficient for a simple two-parameter tool with strong sibling context.
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?
Though schema description coverage is 0%, the description compensates by tying zip_path to 'solution zip' and folder_name to the <output>/unpacked/<folder_name> path. This gives both parameters meaningful semantics beyond their bare titles. It does not explicitly restate folder_name's optionality, but the schema already exposes the default.
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 verb 'Unpack' and the resource 'solution zip', including the underlying command (pac solution unpack) and local-only scope. It also specifies where the output goes, making the tool's function unambiguous and distinct from siblings like pack_solution or import_solution.
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 clear usage context: it is local-only and produces a folder that can be used as source= for offline tools. It does not explicitly name alternatives or state when not to use it, but the practical workflow context is strong enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.