Skip to main content
Glama
severity1

terraform-cloud-mcp

create_project

Create a Terraform Cloud project to organize workspaces into logical groups with configurable settings and permissions.

Instructions

Create a new project in an organization.

Creates a new Terraform Cloud project which serves as a container for workspaces. Projects help organize workspaces into logical groups and can have their own settings and permissions.

API endpoint: POST /organizations/{organization}/projects

Args: organization: The name of the organization name: The name to give the project params: Additional project parameters (optional): - description: Human-readable description of the project - auto_destroy_activity_duration: How long each workspace should wait before auto-destroying (e.g., '14d', '24h') - tag_bindings: List of tag key-value pairs to bind to the project

Returns: The created project data including configuration, settings and metadata

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
organizationYes
nameYes
paramsNo

Implementation Reference

  • Main handler function implementing the create_project tool. It constructs the API payload using Pydantic models, handles special tag_bindings in relationships, and makes a POST request to the Terraform Cloud API to create the project.
    @handle_api_errors
    async def create_project(
        organization: str, name: str, params: Optional[ProjectParams] = None
    ) -> APIResponse:
        """Create a new project in an organization.
    
        Creates a new Terraform Cloud project which serves as a container for workspaces.
        Projects help organize workspaces into logical groups and can have their own
        settings and permissions.
    
        API endpoint: POST /organizations/{organization}/projects
    
        Args:
            organization: The name of the organization
            name: The name to give the project
            params: Additional project parameters (optional):
                - description: Human-readable description of the project
                - auto_destroy_activity_duration: How long each workspace should wait before auto-destroying
                  (e.g., '14d', '24h')
                - tag_bindings: List of tag key-value pairs to bind to the project
    
        Returns:
            The created project data including configuration, settings and metadata
    
        See:
            docs/tools/project.md for reference documentation
        """
        param_dict = params.model_dump(exclude_none=True) if params else {}
        request = ProjectCreateRequest(organization=organization, name=name, **param_dict)
    
        # Create the base payload
        payload = create_api_payload(
            resource_type="projects", model=request, exclude_fields={"organization"}
        )
    
        # Handle tag bindings if present
        if request.tag_bindings:
            tag_bindings_data = []
            for tag in request.tag_bindings:
                tag_bindings_data.append(
                    {
                        "type": "tag-bindings",
                        "attributes": {"key": tag.key, "value": tag.value},
                    }
                )
    
            if "relationships" not in payload["data"]:
                payload["data"]["relationships"] = {}
    
            payload["data"]["relationships"]["tag-bindings"] = {"data": tag_bindings_data}
    
        # Remove tag-bindings from attributes if present since we've moved them to relationships
        if "tag-bindings" in payload["data"]["attributes"]:
            del payload["data"]["attributes"]["tag-bindings"]
    
        logger = logging.getLogger(__name__)
        logger.debug(f"Create project payload: {payload}")
    
        return await api_request(
            f"organizations/{organization}/projects", method="POST", data=payload
        )
  • Registration of the create_project tool in the MCP server using the mcp.tool decorator with write permissions configuration.
    mcp.tool(**write_tool_config)(projects.create_project)
  • Pydantic schema model ProjectCreateRequest used internally in the handler for payload creation and validation.
    class ProjectCreateRequest(BaseProjectRequest):
        """Request model for creating a Terraform Cloud project.
    
        Validates and structures the request according to the Terraform Cloud API
        requirements for creating projects. Extends BaseProjectRequest with
        required fields for creation.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/projects#create-a-project
    
        Note:
            This inherits all configuration fields from BaseProjectRequest
            while making organization and name required.
    
        See:
            docs/models/project.md for reference
        """
    
        # Organization is needed for routing but not included in the payload
        organization: str = Field(
            ...,
            description="The name of the organization to create the project in",
        )
    
        # Override name to make it required for creation
        name: str = Field(
            ...,
            description="Name of the project",
        )
  • Base Pydantic schema defining optional parameters (name, description, auto_destroy_activity_duration, tag_bindings) used via ProjectParams in the tool function signature.
    class BaseProjectRequest(APIRequest):
        """Base class for project create and update requests with common fields.
    
        This includes common fields used in request payloads for project
        creation and update APIs, providing a foundation for more specific project models.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/projects
    
        Note:
            This class inherits model_config from APIRequest -> BaseModelConfig and provides
            default values for fields based on Terraform Cloud API defaults.
    
        See:
            docs/models/project.md for detailed field descriptions and usage examples
        """
    
        # Fields common to both create and update requests
        name: Optional[str] = Field(
            None,
            description="Name of the project",
        )
        description: Optional[str] = Field(
            None,
            description="Description of the project",
        )
        auto_destroy_activity_duration: Optional[str] = Field(
            None,
            alias="auto-destroy-activity-duration",
            description="How long each workspace should wait before auto-destroying (e.g., '14d', '24h')",
        )
        tag_bindings: Optional[List[TagBinding]] = Field(
            None,
            alias="tag-bindings",
            description="Tags to bind to the project, inherited by workspaces",
        )
  • Pydantic schema for individual tag bindings used in project creation.
    class TagBinding(APIRequest):
        """Tag binding configuration for a project.
    
        Defines a tag key-value pair that can be bound to a project
        and inherited by its workspaces.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/projects
    
        See:
            docs/models/project.md for reference
        """
    
        # Inherits model_config from APIRequest -> BaseModelConfig
    
        key: str = Field(..., description="The key of the tag")
        value: str = Field(..., description="The value of the tag")
Behavior4/5

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

Annotations provide readOnlyHint=false (indicating a write operation), which aligns with the 'Create' action. The description adds valuable behavioral context beyond annotations: it explains the purpose of projects ('container for workspaces'), mentions they can have settings and permissions, and provides the API endpoint. However, it doesn't disclose rate limits, authentication requirements, or error behaviors.

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

Conciseness4/5

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

The description is well-structured with clear sections (purpose, API endpoint, args, returns, see). It's appropriately sized for a creation tool with multiple parameters. Some redundancy exists (e.g., auto_destroy_activity_duration appears twice), but overall it's efficient and front-loaded with the core purpose.

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

Completeness4/5

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

For a creation tool with 3 parameters, 0% schema coverage, no output schema, and minimal annotations, the description provides substantial context: purpose, parameter details, return value description, and API reference. It adequately compensates for the lack of structured documentation, though could benefit from more behavioral details like error handling.

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 carries the full burden of parameter documentation. It successfully explains all 3 parameters: 'organization' (name of organization), 'name' (name to give project), and 'params' with detailed sub-parameters including descriptions and examples like '14d' for auto_destroy_activity_duration. This adds significant value 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 ('Create a new project'), the resource ('in an organization'), and the platform context ('Terraform Cloud project'). It distinguishes from siblings like 'create_organization' or 'create_workspace' by specifying it creates a project as a container for workspaces, not other resource types.

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: to create a Terraform Cloud project for organizing workspaces. It doesn't explicitly state when NOT to use it or name specific alternatives, but the context implies it's for project creation versus other creation tools like 'create_workspace' or 'create_organization'.

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