Skip to main content
Glama

duplicateCollection

Copy a Postman collection to another workspace, returning a task ID for status tracking. Optionally add a suffix to the duplicated collection name.

Instructions

Duplicates a collection to another workspace. Returns a task ID - use getDuplicateCollectionTaskStatus to check status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
collectionIdYesThe collection's unique ID
workspaceYesTarget workspace ID
suffixNoOptional suffix for duplicated collection name

Implementation Reference

  • The DuplicateCollectionTool class implements the 'duplicateCollection' tool. It extends ToolHandler, registers with name 'duplicateCollection', defines input schema requiring 'collectionId' and 'workspace' with optional 'suffix', and its run_tool method POSTs to /collections/{collection_id}/duplicate.
    class DuplicateCollectionTool(ToolHandler):
        """Duplicate a collection to another workspace"""
        
        def __init__(self):
            super().__init__("duplicateCollection")
        
        def get_tool_description(self) -> Tool:
            return Tool(
                name=self.name,
                description="Duplicates a collection to another workspace. Returns a task ID - use getDuplicateCollectionTaskStatus to check status.",
                inputSchema={
                    "type": "object",
                    "properties": {
                        "collectionId": {
                            "type": "string",
                            "description": "The collection's unique ID"
                        },
                        "workspace": {
                            "type": "string",
                            "description": "Target workspace ID"
                        },
                        "suffix": {
                            "type": "string",
                            "description": "Optional suffix for duplicated collection name"
                        }
                    },
                    "required": ["collectionId", "workspace"]
                },
            )
        
        async def run_tool(self, args: dict) -> list[TextContent]:
            collection_id = args["collectionId"]
            body = {"workspace": args["workspace"]}
            if args.get("suffix"):
                body["suffix"] = args["suffix"]
            
            result = await postman_api_call("POST", f"/collections/{collection_id}/duplicate", body=body)
            return [TextContent(type="text", text=json.dumps(result, indent=2))]
  • The schema definition for the duplicateCollection tool. It defines the input as an object with required fields 'collectionId' (string) and 'workspace' (string), and an optional 'suffix' (string).
    def get_tool_description(self) -> Tool:
        return Tool(
            name=self.name,
            description="Duplicates a collection to another workspace. Returns a task ID - use getDuplicateCollectionTaskStatus to check status.",
            inputSchema={
                "type": "object",
                "properties": {
                    "collectionId": {
                        "type": "string",
                        "description": "The collection's unique ID"
                    },
                    "workspace": {
                        "type": "string",
                        "description": "Target workspace ID"
                    },
                    "suffix": {
                        "type": "string",
                        "description": "Optional suffix for duplicated collection name"
                    }
                },
                "required": ["collectionId", "workspace"]
            },
  • The DuplicateCollectionTool is registered in the register_all_tools() function at line 1843, alongside other collection tools.
    def register_all_tools() -> list[ToolHandler]:
        """Register all Postman tool handlers"""
        return [
            # User Info
            GetAuthenticatedUserTool(),
            GetEnabledToolsTool(),
            
            # Collections
            CreateCollectionTool(),
            GetCollectionTool(),
            GetCollectionsTool(),
            PutCollectionTool(),
            DuplicateCollectionTool(),
            GetDuplicateCollectionTaskStatusTool(),
  • The ToolHandler abstract base class that DuplicateCollectionTool extends. Provides the interface with name, get_tool_description(), and run_tool() methods.
    class ToolHandler(ABC):
        """Base class for all Postman tool handlers"""
        
        def __init__(self, name: str):
            self.name = name
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It indicates the operation is asynchronous (returns a task ID) but does not mention whether the original collection remains, potential destructive behavior, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two short sentences. The main action is front-loaded, and every word serves a purpose. No unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters, no output schema, and no annotations, the description is adequate but not complete. It covers the basic purpose and asynchronous nature but omits behavioral details like whether the operation is copy (not move) and error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which already clearly define collectionId, workspace, and suffix.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (duplicates), the resource (collection), and the target (another workspace). It also specifies the return type (task ID) and cross-references a sibling tool for status checking. This distinguishes it from other collection-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives like createCollection or putCollection. It mentions the status tool but lacks context on prerequisites, scenarios, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sourav4670/postman-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server