Skip to main content
Glama
severity1

terraform-cloud-mcp

list_projects

Retrieve and filter projects in a Terraform Cloud organization to manage infrastructure resources effectively.

Instructions

List projects in an organization.

Retrieves a paginated list of all projects in a Terraform Cloud organization. Results can be filtered using a search string or permissions filters to find specific projects.

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

Args: organization: The name of the organization to list projects from page_number: The page number to return (default: 1) page_size: The number of items per page (default: 20, max: 100) q: Optional search query to filter projects by name filter_names: Filter projects by name (comma-separated list) filter_permissions_update: Filter projects that the user can update filter_permissions_create_workspace: Filter projects that the user can create workspaces in sort: Sort projects by name ('name' or '-name' for descending)

Returns: Paginated list of projects with their configuration settings and metadata

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
organizationYes
page_numberNo
page_sizeNo
qNo
filter_namesNo
filter_permissions_updateNo
filter_permissions_create_workspaceNo
sortNo

Implementation Reference

  • The main handler function for the 'list_projects' tool. It validates input using ProjectListRequest model, builds query params, and makes a GET request to the Terraform Cloud API endpoint /organizations/{organization}/projects.
    @handle_api_errors
    async def list_projects(
        organization: str,
        page_number: int = 1,
        page_size: int = 20,
        q: Optional[str] = None,
        filter_names: Optional[str] = None,
        filter_permissions_update: Optional[bool] = None,
        filter_permissions_create_workspace: Optional[bool] = None,
        sort: Optional[str] = None,
    ) -> APIResponse:
        """List projects in an organization.
    
        Retrieves a paginated list of all projects in a Terraform Cloud organization.
        Results can be filtered using a search string or permissions filters to find
        specific projects.
    
        API endpoint: GET /organizations/{organization}/projects
    
        Args:
            organization: The name of the organization to list projects from
            page_number: The page number to return (default: 1)
            page_size: The number of items per page (default: 20, max: 100)
            q: Optional search query to filter projects by name
            filter_names: Filter projects by name (comma-separated list)
            filter_permissions_update: Filter projects that the user can update
            filter_permissions_create_workspace: Filter projects that the user can create workspaces in
            sort: Sort projects by name ('name' or '-name' for descending)
    
        Returns:
            Paginated list of projects with their configuration settings and metadata
    
        See:
            docs/tools/project.md for reference documentation
        """
        # Create request using Pydantic model for validation
        request = ProjectListRequest(
            organization=organization,
            page_number=page_number,
            page_size=page_size,
            q=q,
            filter_names=filter_names,
            filter_permissions_update=filter_permissions_update,
            filter_permissions_create_workspace=filter_permissions_create_workspace,
            sort=sort,
        )
    
        # Use the unified query params utility function
        params = query_params(request)
    
        # Make API request
        return await api_request(
            f"organizations/{organization}/projects", method="GET", params=params
        )
  • Pydantic model defining the input schema and validation for the list_projects tool parameters, including organization, pagination, filters, and sort options.
    class ProjectListRequest(APIRequest):
        """Request parameters for listing projects in an organization.
    
        Defines the parameters for the project listing API including pagination
        and search filtering options.
    
        Reference: https://developer.hashicorp.com/terraform/cloud-docs/api-docs/projects#list-projects
    
        See:
            docs/models/project.md for reference
        """
    
        organization: str = Field(
            ...,
            description="The name of the organization to list projects from",
            min_length=3,
            pattern=r"^[a-z0-9][-a-z0-9_]*[a-z0-9]$",
        )
        page_number: Optional[int] = Field(1, ge=1, description="Page number to fetch")
        page_size: Optional[int] = Field(
            20, ge=1, le=100, description="Number of results per page"
        )
        q: Optional[str] = Field(None, description="Search query for name")
        filter_names: Optional[str] = Field(
            None, description="Filter projects by name (comma-separated)"
        )
        filter_permissions_update: Optional[bool] = Field(
            None, description="Filter projects by update permission"
        )
        filter_permissions_create_workspace: Optional[bool] = Field(
            None, description="Filter projects by create workspace permission"
        )
        sort: Optional[str] = Field(
            None, description="Sort projects by name ('name' or '-name' for descending)"
        )
  • Registration of the list_projects tool using the MCP decorator mcp.tool() on the projects.list_projects function.
    mcp.tool()(projects.list_projects)
Behavior4/5

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

With no annotations provided, the description carries full burden and does well at disclosing key behavioral traits. It explicitly states the tool is for retrieval (not mutation), mentions pagination behavior, filtering capabilities, and provides the API endpoint. It doesn't cover rate limits, authentication needs, or error handling, but gives substantial operational context beyond basic purpose.

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). While slightly longer than minimal, every sentence earns its place by providing essential information. The front-loaded purpose statement is clear, and the parameter explanations are necessary given the poor schema coverage.

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 tool with 8 parameters, 0% schema description coverage, no annotations, and no output schema, the description provides substantial context. It covers purpose, parameters, pagination behavior, filtering options, and return format. The main gap is lack of output structure details, but given the complexity and poor structured data support, it's quite comprehensive.

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 for 8 parameters, the description provides excellent compensation by explaining all parameters in the 'Args' section with clear semantics, defaults, constraints, and usage examples. It adds significant meaning beyond what the bare schema provides, including parameter purposes, default values, maximums, and format details like comma-separated lists.

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 tool's purpose with specific verb ('List', 'Retrieves') and resource ('projects in an organization', 'all projects in a Terraform Cloud organization'). It distinguishes from siblings by focusing specifically on listing projects rather than creating, updating, or managing them, which are covered by other tools like create_project, update_project, and get_project_details.

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 for when to use this tool: to retrieve a paginated list of projects with optional filtering. It doesn't explicitly state when NOT to use it or name specific alternatives, but the context of sibling tools (like get_project_details for single project details) implies differentiation. The mention of filtering capabilities helps guide usage decisions.

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