Skip to main content
Glama
Eminemminem

BlenderMCP

by Eminemminem

get_polyhaven_categories

Retrieve category lists for Polyhaven assets to organize and filter 3D resources in Blender. Specify asset type (HDRI, textures, models) to access structured browsing options.

Instructions

Get a list of categories for a specific asset type on Polyhaven.

Parameters:

  • asset_type: The type of asset to get categories for (hdris, textures, models, all)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asset_typeNohdris

Implementation Reference

  • The core handler implementation for the get_polyhaven_categories MCP tool. It proxies the request to the Blender addon via socket command, handles PolyHaven enabled check, formats and sorts the categories response for user readability.
    @mcp.tool()
    def get_polyhaven_categories(ctx: Context, asset_type: str = "hdris") -> str:
        """
        Get a list of categories for a specific asset type on Polyhaven.
        
        Parameters:
        - asset_type: The type of asset to get categories for (hdris, textures, models, all)
        """
        try:
            blender = get_blender_connection()
            if not _polyhaven_enabled:
                return "PolyHaven integration is disabled. Select it in the sidebar in BlenderMCP, then run it again."
            result = blender.send_command("get_polyhaven_categories", {"asset_type": asset_type})
            
            if "error" in result:
                return f"Error: {result['error']}"
            
            # Format the categories in a more readable way
            categories = result["categories"]
            formatted_output = f"Categories for {asset_type}:\n\n"
            
            # Sort categories by count (descending)
            sorted_categories = sorted(categories.items(), key=lambda x: x[1], reverse=True)
            
            for category, count in sorted_categories:
                formatted_output += f"- {category}: {count} assets\n"
            
            return formatted_output
        except Exception as e:
            logger.error(f"Error getting Polyhaven categories: {str(e)}")
            return f"Error getting Polyhaven categories: {str(e)}"
  • Input schema documentation for the tool, specifying the asset_type parameter and its possible values.
    """
    Get a list of categories for a specific asset type on Polyhaven.
    
    Parameters:
    - asset_type: The type of asset to get categories for (hdris, textures, models, all)
    """
  • MCP tool registration decorator that registers the get_polyhaven_categories function as an MCP tool.
    @mcp.tool()

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It accurately signals a read-only operation ('Get a list'), but it does not disclose return format, network dependency, or error behavior. For a simple list operation this is adequate but not rich.

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 compact, with the core action front-loaded and a structured parameter list. However, the parameter list partially duplicates the schema, even though it adds the allowed values.

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?

With one optional parameter and no output schema, the description covers the main semantic need: what categories are for and the allowed asset types. It lacks an explicit return-format note, but 'list of categories' implies an array of names. Minor gap: no statement about the default when asset_type is omitted, though the schema covers this.

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?

The description's Parameters section provides the accepted values for asset_type (hdris, textures, models, all), which the schema omits. This adds critical meaning beyond the schema's bare string type and default.

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 states 'Get a list of categories for a specific asset type on Polyhaven' – a precise verb+resource. This clearly distinguishes it from siblings like search_polyhaven_assets, download_polyhaven_asset, and get_polyhaven_status, which concern asset search, download, and service status.

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?

No guidance on when to use this tool versus alternatives. It does not specify a workflow (e.g., fetch categories before searching assets) or any exclusions. The parameter list is not usage guidance.

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