Skip to main content
Glama

add_enumeration_restriction

Restrict parameter values to a defined list in IDS specifications to ensure compliance with allowed enumerations for buildingSMART standards.

Instructions

Add enumeration restriction (list of allowed values).

Args: spec_id: Specification identifier or name facet_index: Index of facet in location (0-based) parameter_name: Which parameter to restrict (e.g., "value", "propertySet") base_type: XSD base type (e.g., "xs:string", "xs:integer") values: List of allowed values ctx: FastMCP Context (auto-injected) location: "applicability" or "requirements" (default: "requirements")

Returns: {"status": "added", "restriction_type": "enumeration", "spec_id": "S1"}

Example: Add enumeration to property value: FireRating must be "REI30", "REI60", or "REI90"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spec_idYes
facet_indexYes
parameter_nameYes
base_typeYes
valuesYes
locationNorequirements

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The core handler function for the 'add_enumeration_restriction' tool. It retrieves a specification, locates the target facet, creates an enumeration Restriction using the IfcTester IDS library, applies it to the specified parameter, and returns success details.
    async def add_enumeration_restriction(
        spec_id: str,
        facet_index: int,
        parameter_name: str,
        base_type: str,
        values: List[str],
        ctx: Context,
        location: str = "requirements"
    ) -> Dict[str, Any]:
        """
        Add enumeration restriction (list of allowed values).
    
        Args:
            spec_id: Specification identifier or name
            facet_index: Index of facet in location (0-based)
            parameter_name: Which parameter to restrict (e.g., "value", "propertySet")
            base_type: XSD base type (e.g., "xs:string", "xs:integer")
            values: List of allowed values
            ctx: FastMCP Context (auto-injected)
            location: "applicability" or "requirements" (default: "requirements")
    
        Returns:
            {"status": "added", "restriction_type": "enumeration", "spec_id": "S1"}
    
        Example:
            Add enumeration to property value: FireRating must be "REI30", "REI60", or "REI90"
        """
        try:
            ids_obj = await get_or_create_session(ctx)
            spec = _find_specification(ids_obj, spec_id)
    
            await ctx.info(f"Adding enumeration restriction to {spec_id}, facet {facet_index}")
    
            # Get the facet
            facet = _get_facet_from_spec(spec, location, facet_index)
    
            # Create enumeration restriction using IfcTester
            # Normalize base type (remove 'xs:' prefix if present)
            normalized_base = _normalize_base_type(base_type)
            restriction = ids.Restriction(
                base=normalized_base,
                options={"enumeration": values}
            )
    
            # Apply restriction to the parameter
            _apply_restriction_to_facet(facet, parameter_name, restriction)
    
            await ctx.info(f"Enumeration restriction added with {len(values)} values")
    
            return {
                "status": "added",
                "restriction_type": "enumeration",
                "spec_id": spec_id,
                "facet_index": facet_index,
                "parameter": parameter_name,
                "value_count": len(values)
            }
    
        except ToolError:
            raise
        except Exception as e:
            await ctx.error(f"Failed to add enumeration restriction: {str(e)}")
            raise ToolError(f"Failed to add enumeration restriction: {str(e)}")
  • Registers the 'add_enumeration_restriction' tool function with the FastMCP server instance.
    mcp_server.tool(restrictions.add_enumeration_restriction)
  • Helper function that applies the Restriction object to the specified parameter on the facet object.
    def _apply_restriction_to_facet(
        facet: Any,
        parameter_name: str,
        restriction: ids.Restriction
    ) -> None:
        """
        Apply restriction to a facet parameter.
    
        Args:
            facet: Facet object (Entity, Property, Attribute, etc.)
            parameter_name: Parameter to restrict (e.g., "value", "propertySet", "baseName")
            restriction: Restriction object to apply
    
        Raises:
            ToolError: If parameter doesn't exist on facet
        """
        # Check if parameter exists
        if not hasattr(facet, parameter_name):
            raise ToolError(
                f"Parameter '{parameter_name}' not found on facet type {type(facet).__name__}"
            )
    
        # Set the restriction on the parameter
        setattr(facet, parameter_name, restriction)
  • Helper function to retrieve a specific facet from the specification's applicability or requirements list.
    def _get_facet_from_spec(
        spec: ids.Specification,
        location: str,
        facet_index: int
    ) -> Any:
        """
        Get facet from specification by location and index.
    
        Args:
            spec: Specification object
            location: "applicability" or "requirements"
            facet_index: Index of facet in location (0-based)
    
        Returns:
            Facet object
    
        Raises:
            ToolError: If location invalid or index out of range
        """
        if location == "applicability":
            facets = spec.applicability
        elif location == "requirements":
            facets = spec.requirements
        else:
            raise ToolError(f"Invalid location: {location}. Must be 'applicability' or 'requirements'")
    
        if facet_index < 0 or facet_index >= len(facets):
            raise ToolError(
                f"Facet index {facet_index} out of range. "
                f"Location '{location}' has {len(facets)} facet(s)"
            )
    
        return facets[facet_index]
  • Helper function to normalize the base_type by removing 'xs:' prefix if present, as required by IfcTester.
    def _normalize_base_type(base_type: str) -> str:
        """
        Normalize XML Schema base type for IfcTester.
    
        IfcTester adds 'xs:' prefix automatically, so we need to remove it if present.
    
        Args:
            base_type: Base type (e.g., "xs:string" or "string")
    
        Returns:
            Normalized base type without 'xs:' prefix (e.g., "string")
        """
        if base_type.startswith("xs:"):
            return base_type[3:]  # Remove 'xs:' prefix
        return base_type
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that this is a write operation ('Add'), implies it modifies specifications, and shows the return format. However, it doesn't mention permissions needed, whether changes are reversible, error conditions, or rate limits. The example helps but doesn't fully cover behavioral traits for a mutation tool.

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 appropriately sized. It starts with a clear purpose statement, lists args with brief explanations, shows returns, and provides a concrete example. Every sentence earns its place, with no redundant information. The formatting (bullet-like args list) enhances readability.

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?

Given 6 parameters with 0% schema coverage and no annotations, the description does a good job explaining most parameters and the tool's purpose. The output schema is provided via the Returns section, so return values are documented. However, for a mutation tool with complex parameters, it could benefit from more behavioral context (e.g., error handling, idempotency).

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all parameters: 'spec_id' as 'Specification identifier or name', 'facet_index' as 'Index of facet in location (0-based)', etc. The example illustrates how 'parameter_name' and 'values' work. However, it doesn't explain 'ctx' (auto-injected) or provide format details for 'base_type' beyond examples.

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: 'Add enumeration restriction (list of allowed values)' with a specific verb ('Add'), resource ('enumeration restriction'), and scope. It distinguishes from siblings like 'add_bounds_restriction' or 'add_pattern_restriction' by specifying the restriction type. The example further clarifies by showing it restricts property values to specific enumerated options.

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 add enumeration restrictions to parameters in specifications. It mentions the 'location' parameter defaulting to 'requirements', implying usage in that context. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., when to choose 'add_bounds_restriction' instead).

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/vinnividivicci/ifc-ids-mcp'

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