Skip to main content
Glama
severity1

terraform-cloud-mcp

move_workspaces_to_project

Move Terraform Cloud workspaces into a specified project by providing project and workspace IDs. Organize infrastructure management by grouping related workspaces together.

Instructions

Move workspaces into a project.

Moves one or more workspaces into a project. The user must have permission to move workspaces on both source and destination projects.

API endpoint: POST /projects/{project_id}/relationships/workspaces

Args: project_id: The ID of the destination project (format: "prj-xxxxxxxx") workspace_ids: List of workspace IDs to move (format: ["ws-xxxxxxxx", ...])

Returns: Empty response with HTTP 204 status code if successful

See: docs/tools/project.md for reference documentation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
workspace_idsYes

Implementation Reference

  • The main handler function that implements the tool logic by validating inputs with WorkspaceMoveRequest model and making a POST API request to move workspaces into the specified project.
    @handle_api_errors
    async def move_workspaces_to_project(
        project_id: str, workspace_ids: List[str]
    ) -> APIResponse:
        """Move workspaces into a project.
    
        Moves one or more workspaces into a project. The user must have permission
        to move workspaces on both source and destination projects.
    
        API endpoint: POST /projects/{project_id}/relationships/workspaces
    
        Args:
            project_id: The ID of the destination project (format: "prj-xxxxxxxx")
            workspace_ids: List of workspace IDs to move (format: ["ws-xxxxxxxx", ...])
    
        Returns:
            Empty response with HTTP 204 status code if successful
    
        See:
            docs/tools/project.md for reference documentation
        """
        # Create request using Pydantic model
        request = WorkspaceMoveRequest(project_id=project_id, workspace_ids=workspace_ids)
    
        # Create payload
        payload: Dict[str, List[Dict[str, str]]] = {"data": []}
        for workspace_id in request.workspace_ids:
            payload["data"].append({"type": "workspaces", "id": workspace_id})
    
        # Make API request
        return await api_request(
            f"projects/{project_id}/relationships/workspaces", method="POST", data=payload
        )
  • Pydantic model defining the input schema for the tool, including required project_id and list of workspace_ids with descriptions and validation.
    class WorkspaceMoveRequest(APIRequest):
        """Request model for moving workspaces into a project.
    
        This model is used for the POST /projects/{project_id}/relationships/workspaces endpoint,
        which allows moving one or more workspaces into a project.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/projects#move-workspaces-into-a-project
    
        See:
            docs/models/project.md for reference
        """
    
        project_id: str = Field(
            ...,
            description="The ID of the destination project",
        )
        workspace_ids: List[str] = Field(
            ...,
            description="The IDs of workspaces to move into the project",
        )
  • Registers the move_workspaces_to_project function as an MCP tool with write permissions using the FastMCP decorator.
    mcp.tool(**write_tool_config)(projects.move_workspaces_to_project)
Behavior4/5

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

Annotations indicate readOnlyHint=false (implying a mutation), which aligns with the description's 'Move' action. The description adds valuable behavioral context beyond annotations: it specifies permission requirements, mentions the API endpoint, and notes the return behavior ('Empty response with HTTP 204 status code if successful'). This provides practical implementation details that annotations don't cover.

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 well-structured and efficiently front-loaded with the core purpose. Each sentence adds value: purpose statement, permission context, API endpoint, parameter details, return behavior, and documentation reference. There is no wasted text, and information is logically organized.

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

Completeness5/5

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

Given this is a mutation tool with 2 parameters, 0% schema coverage, no output schema, and annotations only covering readOnlyHint, the description provides excellent completeness. It explains the tool's purpose, usage context, behavioral details (permissions, API, response), parameter semantics, and points to further documentation, covering all essential aspects for effective use.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by clearly explaining both parameters: 'project_id: The ID of the destination project (format: "prj-xxxxxxxx")' and 'workspace_ids: List of workspace IDs to move (format: ["ws-xxxxxxxx", ...])'. It provides format examples and clarifies their roles, adding substantial meaning beyond the bare schema.

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 specific action ('Move workspaces into a project') with the exact resources involved ('workspaces', 'project'). It distinguishes this tool from siblings like 'create_workspace', 'update_workspace', or 'list_workspaces' by focusing on relocation rather than creation, modification, or listing.

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

Usage Guidelines4/5

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

The description provides clear context about when to use this tool ('Moves one or more workspaces into a project') and mentions a prerequisite ('The user must have permission to move workspaces on both source and destination projects'). However, it does not explicitly state when NOT to use it or name specific alternative tools for related operations.

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/severity1/terraform-cloud-mcp'

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